[RFA][PATCH 1b/4] [PR tree-optimization/33562] Improve DSE of complex stores

Jeff Law law@redhat.com
Fri May 5 15:29:00 GMT 2017


On 05/05/2017 08:04 AM, Richard Sandiford wrote:
>> It was primarily to avoid mucking up alignments of the start of the copy
>> or leaving residuals at the end of a copy.  It's an idea I saw while
>> scanning the LLVM implementation of DSE.  The fact that it avoids
>> mucking things up for tree-ssa-strlen was a unplanned side effect.
> 
> OK.  Why 2 bytes though?  I wouldn't have expected that misaligning
> to x+2 would be significantly better than misaligning to x+3.
No particular reason.  In retrospect, aligning to words would have been 
better.  I wouldn't lose sleep if we had to adjust the testcases if they 
don't fire with the higher alignment requirements.

> And subtracting odd values could sometimes give a nicer alignment
> than we had before.
True.  My thought process was that more often than not the object's 
alignment & size would be "good" and thus we should avoid mis-aligning 
the start and size.  But that's about the extent of my thought process.

> 
> Would it make sense to limit the head trims to multiples of the pointer
> alignment, or perhaps the minimum of the pointer alignment and the word
> size?  And limit tail trims based on the alignment of the new size,
> rather than the alignment of the value that's being subtracted from
> the size?
That probably would make more sense.  Remember that we've biased 
everything to start at 0 for the sbitmaps, so you'd have to go back to 
the ao_ref to get the actual starting offset within the object.


> 
>> I never did any real benchmarking either way.  If you've got any hard
>> data which shows it's a bad idea, then let's remove it and deal with the
>> tree-ssa-strlen stuff (as I noted you'd done this morning).
> 
> TBH I don't have any performance data either.  This was just something
> that came up with the SVE changes, where the offsets could have a
> runtime component.
> 
> I can preserve the current mask fairly easily if we want to keep it.
> I just wasn't quite sure how to explain it away.
I don't consider the masking a big deal.  I'd meant to come back and 
review it at some point, but like so many things, it gets pushed onto 
the stack and getting back to it is hard.  I'm certainly willing to go 
with any reasonably thought out scheme here.

jeff



More information about the Gcc-patches mailing list