> The calls should still be diagnosed as incorrect, even if we don't
> code-generate them. The fact that we don't do that is a known bug
> (in aarch64 code).
OK, thanks for the explanation.
> The new variables seem to be unused, so I think slightly stronger
> DCE could remove the calls even after the patch. Perhaps the containing
> functions should take an int32x4_t *ptr or something, with the calls
> assigning to different ptr[] indices.
We run a minimal DCE pass at -O0 in our compiler to eliminate all the garbage
generated by the gimplifier for variable-sized types (people care about code
size at -O0 in specific contexts) but it does not touch anything written by
the user (and debugging is unaffected of course). Given that the builtins are
pure functions and the arguments have no side effects, it eliminates the
calls, but adding a LHS blocks that because this minimal DCE pass preserves
anything user-related, in particular assignments to user variables.
> I think it would be better to do that using new calls though,
> and xfail the existing ones when they no longer work. For example:
>
> /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */
> vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1);
> /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */
> ptr[0] = vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1);
>
> That way we don't lose the existing tests.
Frankly I'm not quite sure of what we can lose by adding a LHS here, can you
elaborate a bit? We would need a solution that works out of the box with our
compiler in the future, i.e. without having to tweak 50 testcases again.
--
Eric Botcazou
