Re: PR gcc/7618: Support MI thunks in the MIPS backend

[Richard Sandiford <rsandifo at redhat dot com>]

[combining replies to several messages]

Thanks for working on this.

Ian Lance Taylor <ian@wasabisystems.com> writes:
>> - It's always difficult writing out MIPS asm directly.  There are so
>>   many variations to worry about.  (At least 6 ABI variations that
>>   I think of as supported, plus PIC/no-PIC and mips16/non-mips16.)
>> 
>>   The necessary logic is already present elsewhere in the compiler,
>>   but it's all geared towards rtl.  If we're trying to write out
>>   the asm directly, we end up having to duplicate a lot of it.
>
> Sure.  I punted on all that by just relying on the assembler macros
> which we know are there for MIPS targets.  Like it or not, the
> assembler already has to know how to handle all the different
> variations.

I was thinking more generally than just the address access sequence.
We have to worry about other things too, like the different calling
conventions (probably not a problem here) and the different ways of
setting up the gp (definitely a problem here ;).

But I guess you're right that a target-independent approach might
be too complicated.

> Clearly, when using explicit relocs, it should be possible to do lazy
> binding even when using thunks.  However, gas doesn't appear to
> generate them.  I'm not entirely sure why.  I think it's because
> tc_gen_reloc() relaxes CALL16 to GOT_DISP, but I haven't investigated
> why this happens.

As I understand it, the address of both the thunk and the function
it calls are stored in vtables.  Anything like that would be enough
to stop lazy binding.

> And here is a version which works for all cases I've tested.

Hmm... it doesn't look like you're setting up $gp for !TARGET_NEWABI.

Also, it looks like the TARGET_NEWABI version will use $gp as the
global pointer.  That's not right, since $gp is a call-saved register.
(Note that if you use a call-clobbered register instead, you need to
tell the assembler about it, at least when using assembler macros.)

Anyway, since I'm on the hook to test the thing anyway ;), I've been
trying to hack up an alternative implementation.  Hope to have it done
by the weekend.

Richard