On Wed, 30 Sep 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Require non_strict_align in
> pr94600-{1,3}.c ]
>
> On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Sep 2020, Tom de Vries wrote:
> >
> >> Hi,
> >>
> >> With the nvptx target, we run into:
> >> ...
> >> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
> >> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
> >> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
> >> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(set \\(mem/v" 1
> >> ...
> >> The scans attempt to check for volatile stores, but on nvptx we have memcpy
> >> instead.
> >>
> >> This is due to nvptx being a STRICT_ALIGNMENT target, which has the effect
> >> that the TYPE_MODE for the store target is set to BKLmode in
> >> compute_record_mode.
> >>
> >> Fix the FAILs by requiring effective target non_strict_align.
> >
> > No, that's wrong. There's more than that at play; it worked for
> > the strict-alignment targets where it was tested at the time.
> >
>
> Hi,
>
> thanks for letting me know.
>
> > The test is a valuable canary for this kind of bug. You now
> > disabled it for strict-alignment targets.
> >
> > Please revert and add your target specifier instead, if you
> > don't feel like investigating further.
>
> I've analyzed the compilation on strict-alignment target arm-eabi, and
An analysis should result in more than that statement.
> broadened the effective target to (non_strict_align ||
> pcc_bitfield_type_matters).
That's *also* not right. I'm guessing your nvptx fails because
it has 64-bit alignment requirement, but no 32-bit writes.
...um, no that can't be it, nvptx seems to have them. Costs?
Yes, probably your #define MOVE_RATIO(SPEED) 4.
The writes are to 32-bit aligned addresses which gcc can deduce
(also for strict-alignment targets) because it's a literal,
where it isn't explicitly declared to be attribute-aligned
You should have noticed the weirness in that you "only" needed
to tweak pr94600-1.c and -3.c, not even pr94600-2.c, which
should be the case if it was just the test-case getting the
predicates wrong. This points at your MOVE_RATIO, together with
middle-end not applying it consistently for -2.c.
Again, please just skip for nvptx (don't mix-n-match general
predicates) unless you really look into the reason you don't get
6 single 32-bit-writes only in *some* of the cases.
brgds, H-P
