Andreas Schwab wrote:
>
> This breaks gcc.target/aarch64/reload-valid-spoff.c with -mabi=ilp32:
Indeed, there is a odd ILP32 bug that causes high/lo_sum to be generated
in SI mode in expand:
(insn 15 14 16 4 (set (reg:SI 125)
(high:SI (symbol_ref/u:DI ("*.LC1") [flags 0x2])))
(nil))
On Jun 20 2017, Wilco Dijkstra wrote:
> * config/aarch64/aarch64.c (aarch64_legitimate_constant_p):
> Return true for non-tls symbols.
This breaks gcc.target/aarch64/reload-valid-spoff.c with -mabi=ilp32:
/opt/gcc/gcc-20170622/gcc/testsuite/gcc.target/aarch64/reload-valid-spoff.c: I
On 20/06/17 15:56, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>
>> What testing has this had with -fpic? I'm not convinced that this
>> assertion is true in that case?
>
> I ran the GLIBC tests which pass. -fpic works since it does also form a
> constant address, ie. instead of:
>
> adrp
Richard Earnshaw wrote:
> What testing has this had with -fpic? I'm not convinced that this
> assertion is true in that case?
I ran the GLIBC tests which pass. -fpic works since it does also form a
constant address, ie. instead of:
adrp x1, global
add x1, x1, :lo12:global
we do:
adrp x1, :g
On 19/06/17 19:59, Wilco Dijkstra wrote:
> Aarch64_legitimate_constant_p currently returns false for symbols,
> eventhough they are always valid constants. This means LOSYM isn't
> CSEd correctly. If we return true CSE works better, resulting in
> smaller/faster code (0.3% smaller code on SPEC200
Aarch64_legitimate_constant_p currently returns false for symbols,
eventhough they are always valid constants. This means LOSYM isn't
CSEd correctly. If we return true CSE works better, resulting in
smaller/faster code (0.3% smaller code on SPEC2006).
int x0 = 1, x1 = 2, x2 = 3;
int
f (int x,
