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 D
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 w
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 f
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
uses
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
> variable
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 DS
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 u
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 ma
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
> >(match_opera
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)
(mat
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 destinatio
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 gcc.c-torture/execute/20050826-2.c
15 matches
Mail list logo
