On July 3, 2018 5:19:24 PM GMT+02:00, Andrew Stubbs
wrote:
>On 03/07/18 14:52, Richard Biener wrote:
>> If you look at RTL dumps (with -fstrict-aliasing, thus -O2+) you
>should
>> see MEM_ALIAS_SETs differing for the earlier stores and the masked
>> store uses.
>>
>> Now I'm of course assuming
On 03/07/18 14:52, Richard Biener wrote:
If you look at RTL dumps (with -fstrict-aliasing, thus -O2+) you should
see MEM_ALIAS_SETs differing for the earlier stores and the masked
store uses.
Now I'm of course assuming DSE is perfect, maybe it isn't ... ;)
Ok, I see that the stores have MEMs
On Tue, Jul 3, 2018 at 2:46 PM Andrew Stubbs wrote:
>
> On 03/07/18 13:21, Richard Biener wrote:
> > Ok, so if we vectorize the above with 64 element masked stores
> > then indeed the RTL representation is _not_ safe. That is because
> > while the uses in the masked stores should prevent things
On 03/07/18 13:21, Richard Biener wrote:
Ok, so if we vectorize the above with 64 element masked stores
then indeed the RTL representation is _not_ safe. That is because
while the uses in the masked stores should prevent things from
going bad there is also TBAA to consider which means those
On Tue, Jul 3, 2018 at 1:57 PM Andrew Stubbs wrote:
>
> On 03/07/18 12:45, Richard Biener wrote:
> > On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs
> > wrote:
> >>
> >> On 03/07/18 12:30, Richard Biener wrote:
> Hmm, so they're safe, but may prevent the optimization of nearby
>
On 03/07/18 12:45, Richard Biener wrote:
On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs wrote:
On 03/07/18 12:30, Richard Biener wrote:
Hmm, so they're safe, but may prevent the optimization of nearby variables?
Yes, they prevent earlier stores into lanes that are "really" written
to to be
On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs wrote:
>
> On 03/07/18 12:30, Richard Biener wrote:
> >> Hmm, so they're safe, but may prevent the optimization of nearby variables?
> >
> > Yes, they prevent earlier stores into lanes that are "really" written
> > to to be DSEd.
>
> Right, but I have
On 03/07/18 12:30, Richard Biener wrote:
Hmm, so they're safe, but may prevent the optimization of nearby variables?
Yes, they prevent earlier stores into lanes that are "really" written
to to be DSEd.
Right, but I have unrelated variables allocated to the stack within the
"shadow" of the
On Tue, Jul 3, 2018 at 1:06 PM Andrew Stubbs wrote:
>
> On 03/07/18 12:02, Richard Biener wrote:
> > I believe that the AVX variants like
> >
> > (define_expand "maskstore"
> >[(set (match_operand:V48_AVX512VL 0 "memory_operand")
> > (vec_merge:V48_AVX512VL
> >
On 03/07/18 12:02, Richard Biener wrote:
I believe that the AVX variants like
(define_expand "maskstore"
[(set (match_operand:V48_AVX512VL 0 "memory_operand")
(vec_merge:V48_AVX512VL
(match_operand:V48_AVX512VL 1 "register_operand")
(match_dup 0)
On Tue, Jul 3, 2018 at 12:57 PM Andrew Stubbs wrote:
>
> On 03/07/18 11:33, Andrew Stubbs wrote:
> > On 03/07/18 11:15, Richard Biener wrote:
> >> AVX ones are all UNSPECs I believe - how do your patterns look like?
> >
> > AVX has both unspec and vec_merge variants (at least for define_expand,
>
On 03/07/18 11:33, Andrew Stubbs wrote:
On 03/07/18 11:15, Richard Biener wrote:
AVX ones are all UNSPECs I believe - how do your patterns look like?
AVX has both unspec and vec_merge variants (at least for define_expand,
in GCC8), but in any case, AFAICT dse.c only cares about the
On 03/07/18 11:15, Richard Biener wrote:
AVX ones are all UNSPECs I believe - how do your patterns look like?
AVX has both unspec and vec_merge variants (at least for define_expand,
in GCC8), but in any case, AFAICT dse.c only cares about the destination
MEM, and all the AVX and SVE patterns
On Tue, Jul 3, 2018 at 11:59 AM Andrew Stubbs wrote:
>
> Hi All,
>
> I'm trying to implement maskload/maskstore for AMD GCN, which has up-to
> 64-lane, 512-byte fully-masked vectors. All seems fine as far as the
> vector operations themselves go, but I've found a problem with the RTL
> Dead Store
Hi All,
I'm trying to implement maskload/maskstore for AMD GCN, which has up-to
64-lane, 512-byte fully-masked vectors. All seems fine as far as the
vector operations themselves go, but I've found a problem with the RTL
Dead Store Elimination pass.
Testcase
15 matches
Mail list logo
