[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #5 from Richard Sandiford --- (In reply to Andrew Stubbs from comment #4) > Yes, that's what the simd-math-3* tests do. Ah, OK. > The simd-math-5* tests are explicitly supposed to be doing this in the > context of the autovectorizer. > > If these tests are being compiled as (newly) intended then we should change > the expected results. > > So, questions: > > 1. Are the new results actually correct? (So far I only know that being > different is expected.) I believe so. We now do the division in 32 bits, as in the original gimple. > 2. Is there some other testcase form that would exercise the previously > intended routines? It should be possible in languages that don't have C's integer promotion rules, if you're up for some Ada or Rust. > 3. Is the new behaviour configurable? I don't think the 16-bit shift bug> > ever existed on GCN (in which "short" vectors actually have excess bits in > each lane, much like scalar registers do). Not AFAIK. The problem is that the gimple→gimple transformation changes the gimple-level semantics of the code. Shifts by out-of-range values are undefined rather than target-defined. (And in other cases that's useful, because it means we don't need to preserve whatever value the target happens to give for an out-of-range shift.)
[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #4 from Andrew Stubbs --- Yes, that's what the simd-math-3* tests do. The simd-math-5* tests are explicitly supposed to be doing this in the context of the autovectorizer. If these tests are being compiled as (newly) intended then we should change the expected results. So, questions: 1. Are the new results actually correct? (So far I only know that being different is expected.) 2. Is there some other testcase form that would exercise the previously intended routines? 3. Is the new behaviour configurable? I don't think the 16-bit shift bug ever existed on GCN (in which "short" vectors actually have excess bits in each lane, much like scalar registers do).
[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #3 from Richard Sandiford ---
Ah, ok. If the main aim is to test the libgcc routines, it might be safer to
use something like:
typedef char v64qi __attribute__((vector_size(64)));
v64qi f(v64qi x, v64qi y) { return x / y; }
instead of relying on vectorisation.
[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #2 from Andrew Stubbs --- The execution test checks that each of the libgcc routines work correctly, and the scan assembler tests make sure that we're getting coverage of all of them. In this case, the failure indicates that we're not testing the routine we were aiming for (but I think it does execute correctly and give a good result).
[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #1 from Richard Sandiford --- The decision to stop narrowing division was deliberate, see the comments in PR113281 for details. Is the purpose of the test to check vectorisation quality, or to check for the right ABI routines?
[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
