This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: allow certain kinds of inputs to top level asm()-s


On Tue, Jul 06, 2010 at 09:21:56AM +0100, Jan Beulich wrote:
> >>> On 06.07.10 at 10:12, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Tue, Jul 06, 2010 at 08:39:06AM +0100, Jan Beulich wrote:
> >> This is so that use of symbols referenced in these asm()-s can be
> >> properly tracked by the compiler, just like is the case for all other
> >> asm()-s. I'm particularly looking forward to use this in the Linux
> >> kernel.
> > 
> > I'd say it is a bad idea to have in this case the input arguments after
> > first :, there should be two :'s before those.  You can of course for
> > toplevel asms require that there are no output operands (like we already do
> > require e.g. for asm goto).
> 
> I tend to disagree (and intentionally coded it the way it is) - there is,
> afaics, no possible way for top level asm()-s to have outputs. I'm not
> very familiar with asm goto-s yet, but would suspect they can
> theoretically have outputs.

Yes, toplevel asms can't have outputs, sure, but if the first set of
operands means something different between toplevel asms and other asms,
that's just going to cause confusion.

> > Also note that address of symbols with "i" constraint might not work on all
> > targets, certainly won't work on many targets with -fpic/-fPIC (so the
> > testcase needs to be guarded with { target !fpic } or something similar).
> > It might not even work on some targets where -fpic/-fPIC is the default.
> 
> Hmm, that wouldn't be good - the construct ought to work regardless
> of -fPIC imo. I have to admit that I don't see why you think this
> wouldn't work, so any insight would be appreciated.

How could it possibly work?
If you have say:
int i;
asm (".section .rodata; foobar: .long %0; .previous" : : "i" (&i));
you would need to emit code to get the &i value (and, the value would be in
a register, not constant).  That's because for -fpic you need there is an
extra indirection, you need to read i@GOT value from memory and that's the
&i value.
"i" constraint requires:
        case 'i':
          if (CONSTANT_P (op) && (! flag_pic || LEGITIMATE_PIC_OPERAND_P (op)))
            result = 1;
          break;
and it is target's choice what is LEGITIMATE_PIC_OPERAND_P.  "n" allows just
constant integers.
Sure, you could use "X" constraint in that case, do the checking on what
operand is valid in toplevel asms separately and just let the asm writer
deal with -fpic etc. - the user would be responsible for adding @GOT and all
other kinds of special target stuff to actually read the value.  But then
using say .long %0 definitely won't work in many cases, you'll need actual
code to read the value.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]