Markos Chandras <Markos.Chandras@xxxxxxxxxx> writes:
> On 12/19/2014 10:20 AM, Markos Chandras wrote:
> > On 12/18/2014 10:58 PM, Matthew Fortune wrote:
> >> David Daney <ddaney.cavm@xxxxxxxxx> writes:
> >>> On 12/18/2014 01:04 PM, Matthew Fortune wrote:
> >>>>> On Thu, Dec 18, 2014 at 10:50:27AM -0800, David Daney wrote:
> >>>>>
> >>>>>> On 12/18/2014 07:09 AM, Markos Chandras wrote:
> >>>>>>> MIPS R6 changed the opcodes for LL/SC instructions and reduced the
> >>>>>>> offset field to 9-bits. This has some undesired effects with the
> >>> "m"
> >>>>>>> constrain since it implies a 16-bit immediate. As a result of
> >>>>>>> which, add a register ("r") constrain as well to make sure the
> >>>>>>> entire address is loaded to a register before the LL/SC
> operations.
> >>>>>>> Also use macro to set the appropriate ISA for the asm blocks
> >>>>>>>
> >>>>>>
> >>>>>> Has support for MIPS R6 been added to GCC?
> >>>>>>
> >>>>>> If so, that should include a proper constraint to be used with the
> >>>>>> new offset restrictions. We should probably use that, instead of
> >>>>>> forcing to a "r" constraint.
> >>>>>
> >>>>> In a non-public earlier discussion I've requested the same but
> >>>>> somehow that was ignored.
> >>>>
> >>>> I must have missed that comment or not been on the thread.
> >>>>
> >>>>> We need suitable constraints or the alternatives will be very, very
> >>>>> ugly.
> >>>>
> >>>> We can certainly discuss and investigate such things but there is a
> >>>> general problem of a growing list of different size displacement
> >>>> fields in load/store instructions. Obviously you could just opt to
> >>>> keep things the way they are for uMIPS today and leave the assembler
> >>>> to expand the instruction but my opinion is that magic expanding
> >>>> assembler macros are infuriating. We have however had to put support
> >>>> in binutils for many of them, simply to keep enough software building
> >>> to ease the transition.
> >>>>
> >>>> So, all this patch does is highlight that magic assembler macros have
> >>>> been hiding this issue since micromips was added.
> >>>>
> >>>> >From your experiences will people invest the effort to look at the
> >>>> size of a displacement field for all the memory operations in an
> >>>> inline asm block and then choose an appropriate memory constraint?
> >>>>
> >>>> I'm obviously wary of putting things into GCC that are either only
> >>>> used in a handful of places (or not at all). The alternative to
> >>>> constraints is of course to try and reduce the need for inline asm
> and
> >>>> offer builtins for specific instructions or more complex operations.
> >>>>
> >>>
> >>> Well, GCC directly emits LL/SC as part of its built-in support for
> >>> atomic operations, so the knowledge of the constraints for the
> >>> instructions must be present there. Since the constraints must be
> >>> present in GCC, using them in the kernel shouldn't be a problem.
> >>
> >> Yes you are right I thought this particular case only had constraints
> >> for the immediate and not the whole memory operand, I'm suffering from
> >> too many tasks and too little time. Several of the memory constraints
> are
> >> marked as internal and I'm not sure if that means they are unsafe to
> use
> >> from inline asm or just not deemed important.
> >>
> >> The memory constraint that LL and SC need is 'ZC'. I don't believe this
> >> is documented so you will have to trust that its meaning will not
> change
> >> but I can give some assurance of that since I will review all MIPS GCC
> >> changes.
> >>
> >> Obviously to use anything other than the 'm' constraint you are going
> >> to need to know when any given constraint was added to GCC.
> >> 'ZC' was only added to GCC in March 2013 r196828 which I believe it is
> a
> >> GCC 4.9 feature so you will have to use it conditionally if you use it
> at
> >> all.
> >>
> >
> > is this something desirable? check the gcc version, initialize a macro
> > and then use that macro as a constrain? i haven't thought this through,
> > but it could be a bit messy.
> >
> btw i tried a quick test to replace +m with +ZC but i have build
> failures since the immediates do not fit.
>
> {standard input}: Assembler messages:
> {standard input}:436: Error: operand 2 must be constant `ll
> $3,%lo(irq_err_count)($2)'
> {standard input}:438: Error: operand 2 must be constant `sc
> $3,%lo(irq_err_count)($2)'
>
> Could you provide an example of how you would use the ZC constrain in
> these asm blocks? i could be doing something wrong on my end.
In a follow up post I mentioned that you have essentially found something
missing from the R6 GCC implementation. We have just fixed this in our
internal builds so we will have to provide you with an updated compiler to
use ZC. This will be fixed in Imaginations 2015-01 Codescape SDK and will
be posted to GCC following R6 commit (that is a matter of hours away as it
happens).
The reason this was missed from the R6 implementation in GCC is that the
atomic sync patterns in the compiler actually only allow base registers with
no offset (reason unknown) so we will be fixing that too.
Thanks,
Matthew
