https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
Bill Schmidt <wschmidt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wschmidt at gcc dot gnu.org
--- Comment #2 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> note: non-delegitimized UNSPEC
> is just a debugging note solely in non-release checking builds. Not all
> UNSPECs need to be delegitimized, it is just a hint that it is something
> that could be inspected, whether it can be easily delegitimized or not (see
> rs6000_delegitimize_address).
> As UNSPEC_FOO is not in upstream GCC, I fail to see the need for upstream PR.
What may not be crystal clear here is that var-tracking is making a mistake.
The original problem doesn't look quite like the obfuscated one here -- this
came up while working on some future work where an UNSPEC does seem necessary.
We get something like
result = complex-thing-needing-UNSPEC
result = expression-involving-result
where both definitions of result get assigned to the same register, say r31.
The first statement has a var_location note saying result is in r31. The
second statement has a var_location note saying result is in the UNSPEC RTL
generated from complex-thing-needing-UNSPEC.
This is absolutely wrong, because result is once again in r31 at this point;
it's a new lifetime of result, but that's where it is. That's the bug we're
attempting to report here. Unfortunately, as the test was changed to hide
stuff we can't disclose yet, the error message moved to a different place and
another UNSPEC, which as you note is less obviously necessary as an UNSPEC
anyway. But that's an unimportant detail. This var-tracking bug is making it
hard to develop the code for this new feature.
The original test was testing four versions of this instruction, each with a
different mode. Only the V4DI version fails due to the var-tracking error.
So the upstream PR is needed so development can proceed.
> Anyway, I have to wonder why vsx.md uses so many UNSPECs, can't e.g.
> UNSPEC_VSX_SET be just using vec_merge of vec_duplicate of the scalar
> operand (what is inserted) and the vector operand, with the position as last
> operand?
> Is the reason the endian correction?
There are too many unnecessary UNSPECs in the Power back end, yeah. We're
rooting those out as we have time. But this bug shows up with a necessary
UNSPEC originally, so that's not relevant for this report.
