On Sun, May 17, 2020 at 8:23 PM duanbo (C) <duan...@huawei.com> wrote:
>
> Hi,
>
> This changes the definition of Pmode for aarch64 port.
> Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even
> under ILP32.
> Because of that definition, machine mode of symbol_ref which is supposed to
> be SImode becomes DImode under target ILP32.
> Definition of Pmode should depend on the current ABI, i.e., SImode for ILP32
> and DImode for LP64.
> Attached please find the proposed patch .
> Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
> Any suggestion?
THIS DOES NOT WORK correctly and will never work correctly. When I
was originally writing AARCH64 ILP32 (back in 2013), I went this route
first (as it was the fastest way to get it working; I could not wait
on ARM's implementation at the time) but I had regressions.
The place where it fails was something like:
int f(char *g, int t)
{
return g[t];
}
Which you pass -1 for t as there would be no zero-extend any more.
I remember at least one testcase in the testsuite failing due to
implementation this way even; I don't remember which one as I did not
write it down and it was over 6 years ago.
If there was an arch mode which would VAs to be truncated to 32bits,
this would be the correct way to implement this.
The reason why the other ABIs/targets define Pmode as SImode is
because the underlying hardware will extend the VA correctly as Linux
will set the arch bit correctly (NOTE MIPS is an example where
index'ed load/stores which has a similar issue even on MIPS32 but that
is a different story).
Also there are other ABIs where Pmode != PTRmode (e.g. IA64-HPUX32).
x32 has an option which can select either way. The ISA on x86_64
supports both cases which is why it can be selected that way; this is
unlike AARCH64 which cannot.
Thanks,
Andrew Pinski
>
> Thanks,
> Duanbo
