diff options
author | Roger Sayle <roger@nextmovesoftware.com> | 2024-06-11 09:31:34 +0100 |
---|---|---|
committer | Roger Sayle <roger@nextmovesoftware.com> | 2024-06-11 09:31:34 +0100 |
commit | a797398cfbc75899fdb7d97436c0c89c02b133c0 (patch) | |
tree | 622c0a74ffa7c5d70b367bbf11b20aa29f72ef11 /gcc/tree-vect-loop.cc | |
parent | 8087204a4260a552c7cee37d1fb46cec7edfe9ee (diff) | |
download | gcc-a797398cfbc75899fdb7d97436c0c89c02b133c0.zip gcc-a797398cfbc75899fdb7d97436c0c89c02b133c0.tar.gz gcc-a797398cfbc75899fdb7d97436c0c89c02b133c0.tar.bz2 |
i386: PR target/115397: AVX512 ternlog vs. -m32 -fPIC constant pool.
This patch fixes PR target/115397, a recent regression caused by my
ternlog patch that results in an ICE (building numpy) with -m32 -fPIC.
The problem is that ix86_broadcast_from_constant, which calls
get_pool_constant, doesn't handle the UNSPEC_GOTOFF that's created by
calling validize_mem when using -fPIC on i686. The logic here is a bit
convoluted (and my future patches will clean some of this up), but the
simplest fix is to call ix86_broadcast_from_constant between the calls
to force_const_mem and the call to validize_mem.
Perhaps a better solution might be to call targetm.delegitimize_address
from the middle-end's get_pool_constant, but ultimately the best approach
would be to not place things in the constant pool if we don't need to.
My plans to move (broadcast) constant handling from expand to split1
should simplify this.
2024-06-11 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/115397
* config/i386/i386-expand.cc (ix86_expand_ternlog): Move call to
ix86_broadcast_from_constant before call to validize_mem, but after
call to force_const_mem.
gcc/testsuite/ChangeLog
PR target/115397
* gcc.target/i386/pr115397.c: New test case.
Diffstat (limited to 'gcc/tree-vect-loop.cc')
0 files changed, 0 insertions, 0 deletions