aboutsummaryrefslogtreecommitdiff
path: root/gcc/ada
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2021-07-08 12:49:44 +0100
committerRichard Sandiford <richard.sandiford@arm.com>2021-07-08 12:49:44 +0100
commit298b0db76dfcc82427d987fbbd239afcb0c3dbfd (patch)
treeb9a4ed38ef7bd5978d94b6fca062d14034c8eb9b /gcc/ada
parent4c619132b3f14dc5e672a7f2f0e09cb784193559 (diff)
downloadgcc-298b0db76dfcc82427d987fbbd239afcb0c3dbfd.zip
gcc-298b0db76dfcc82427d987fbbd239afcb0c3dbfd.tar.gz
gcc-298b0db76dfcc82427d987fbbd239afcb0c3dbfd.tar.bz2
match.pd: Relax rule to include POLY_INT_CSTs
match.pd has a rule to simplify an extension, operation and truncation back to the original type: (simplify (convert (op:s@0 (convert1?@3 @1) (convert2?@4 @2))) Currently it handles cases in which @2 is an INTEGER_CST, but it also works for POLY_INT_CSTs.[*] For INTEGER_CST it doesn't matter whether we test @2 or @4, but for POLY_INT_CST it is possible to have unfolded (convert …)s. Originally I saw this leading to some bad ivopts decisions, because we weren't folding away redundancies from candidate iv expressions. It's also possible to test the fold directly using the SVE ACLE. [*] Not all INTEGER_CST rules work for POLY_INT_CSTs, since extensions don't necessarily distribute over the internals of the POLY_INT_CST. But in this case that isn't an issue. gcc/ * match.pd: Simplify an extend-operate-truncate sequence involving a POLY_INT_CST. gcc/testsuite/ * gcc.target/aarch64/sve/acle/general/cntb_1.c: New test.
Diffstat (limited to 'gcc/ada')
0 files changed, 0 insertions, 0 deletions