Re: [Patch, MIPS] Fix PR target/68273, passing args in wrong regs

[Richard Biener <richard dot guenther at gmail dot com>]

On February 4, 2016 9:28:22 PM GMT+01:00, Richard Sandiford <rdsandiford@googlemail.com> wrote:
>Richard Biener <richard.guenther@gmail.com> writes:
>> On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou
><ebotcazou@adacore.com> wrote:
>>>> So this doesnât fix aarch64, c6x, epiphany, ia64, iq2000, rs6000,
>rx, sparc,
>>>> tilegx, tilepro or xtensa.
>>>> :-(  Thatâs one of the problems by having each port copy and paste
>swaths of
>>>> :code from other ports to express the same thing instead of ports
>sharing
>>>> :just one copy of code.  My port is also broken in the same way
>>>> :(currently).
>>>
>>> Yes, fixing a compiler bug by changing the ABI is a no-no, and the
>argument of
>>> the compatibility with LLVM has IMO little merit since it's a GCC
>extension.
>>
>> True, but the compiler bug is in the backends - it just now gets
>> exposed more easily
>> (read: w/o user intervention).
>
>I'm still not convinced it's a backend/target bug though.  It seems
>like a similar situation to floats being promoted to doubles and
>chars to ints when passed to unprototyped functions or varargs.
>In those situations it's up to the hook to decide what type the
>value actually gets passed as.  Passing an overaligned int as a
>plain int is pretty similar and isn't something that each target
>should need to check individually.

I agree here.  BUT we are still effectively changing the ABI of each affected target then without actually knowing we do.
I'd happily do such change in the middle-end if we identified all affected targets and verified the changes impact.

That's a lot of work and thus having active targets follow the "arm way" of fixing the issue in the target is very reasonable in my opinion and the only thing I'd accept at this stage.

Richard.

>Thanks,
>Richard