diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2020-01-21 18:22:38 +0000 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2020-01-22 14:33:19 +0000 |
commit | 7c46e71d016c86971ac26c6fa38d76482859f296 (patch) | |
tree | d9688d2364432c863c54b7e08635fa8e9dda8bba /gcc/cp/semantics.c | |
parent | 7491c17fe01d8cf116f645532d46120029b26408 (diff) | |
download | gcc-7c46e71d016c86971ac26c6fa38d76482859f296.zip gcc-7c46e71d016c86971ac26c6fa38d76482859f296.tar.gz gcc-7c46e71d016c86971ac26c6fa38d76482859f296.tar.bz2 |
cfgexpand: Update partition size when merging variables
cfgexpand sorts variables by decreasing size, so when merging a later
variable into an earlier one, there's usually no need to update the
merged size.
But for poly_int sizes, the sort function just uses a lexicographical
comparison of the coefficients, so e.g. 2X+2 comes before 0X+32.
Which is bigger depends on the runtime value of X.
This patch therefore takes the upper bound of the two sizes, which
is conservatively correct for variable-length vectors and a no-op
on other targets.
It's probably a bad idea to merge fixed-length and variable-length
variables in practice, but that's really an optimisation decision.
I think we should have this patch as a correctness fix either way.
This is easiest to test using the ACLE, but in principle it could happen
for autovectorised code too, e.g. when using OpenMP vector variables.
It's therefore a regression from GCC 8.
2020-01-22 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* cfgexpand.c (union_stack_vars): Update the size.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general/stack_vars_1.c: New test.
Diffstat (limited to 'gcc/cp/semantics.c')
0 files changed, 0 insertions, 0 deletions