On Fri, Apr 15, 2005 at 10:18:35AM -0600, Jeffrey A Law wrote:
> I went ahead and ran this through the usual bootstrap and regression
> test. Installed this morning...
>
Excellent. Thanks.
Diego.
On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> >
> > /* Copy the V_MAY_DEFS r
On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> >
> > /* Copy the V_MAY_DEFS r
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> When we vectorize the store we copy the virtual operands from the
> original statement to the new vectorized statement via this code:
>
> /* Copy the V_MAY_DEFS representing the aliasing of the original array
> element's defi
On Fri, 2005-04-08 at 13:39 -0400, Daniel Berlin wrote:
> On Fri, 2005-04-08 at 11:08 -0600, Jeffrey A Law wrote:
> > On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > > > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > > > specifically we lose the V_MAY_DEF for SFT
> > Also, after ivopts, the whole CFG needs to be
> > re-scanned because the new alias relations it creates affect
> > statements that have not even been modified by the process.
> Wow. Egad.
>
Yes, this would be very ungood if it is the case.
If it is really changing the *semantics* of the pr
On Fri, Apr 08, 2005 at 12:04:02PM -0600, Jeffrey A Law wrote:
> On Fri, 2005-04-08 at 13:55 -0400, Diego Novillo wrote:
> > On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> >
> > > It would probably be wise to audit the other uses of
> > > copy_virtual_operands. We might also co
On Fri, 2005-04-08 at 13:58 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 11:44:34AM -0600, Jeffrey A Law wrote:
>
> > For the alias not to be relevant would indicate that vectorization
> > actually improved alias analysis.
> >
> Right. Both ivopts and vectorization have that effect, an
On Fri, 2005-04-08 at 13:41 -0400, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> > On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> >
>
> actually, I'll jsut keep talking to myself here :-)
>
> > > In the interest of brevity, I'm just going to point out the
> >
On Fri, 2005-04-08 at 13:55 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > It would probably be wise to audit the other uses of
> > copy_virtual_operands. We might also consider forcing statement
> > rescans as part of our IL checking code to a
On Fri, Apr 08, 2005 at 11:44:34AM -0600, Jeffrey A Law wrote:
> For the alias not to be relevant would indicate that vectorization
> actually improved alias analysis.
>
Right. Both ivopts and vectorization have that effect, and
that's why the IL needs to be rescanned.
Diego.
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> It would probably be wise to audit the other uses of
> copy_virtual_operands. We might also consider forcing statement
> rescans as part of our IL checking code to avoid these kinds of
> problems in the future.
>
Yes, I've run int
On Fri, 2005-04-08 at 13:27 -0400, Andrew MacLeod wrote:
>
>
> What are these uses?
The later uses are scalar reads from the same memory location.
> If they are references to things that aliased
> *D.1470_8, we should eliminate the VUSE/MAYDEF, shouldnt we? I presume
> they arent relevant any
On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
>
actually, I'll jsut keep talking to myself here :-)
> > In the interest of brevity, I'm just going to point out the
> > problematical store from the .ifcvt dump:
> >
> >
> > # x_16 = V_
On Fri, 2005-04-08 at 11:08 -0600, Jeffrey A Law wrote:
> On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > > specifically we lose the V_MAY_DEF for SFT.3_20.
> >
> > Why?
> >
> > It should be copying subvars to th
On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > specifically we lose the V_MAY_DEF for SFT.3_20. Which results in
> > uses of SFT.3_20 later, but SFT.3_20 is never def
On Fri, Apr 08, 2005 at 07:25:37PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 08, 2005 at 10:11:33AM -0700, Joe Buck wrote:
> > The problem, then, is that there's no way for the user to specify
> > that we have an array whose beginning has, say, 16-byte alignment,
> > but that after that, the elemen
On Fri, 2005-04-08 at 13:26, Devang Patel wrote:
> On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
>
> > On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> >>> When we rescan the operands, we get a different set of V_MAY_DEFS,
> >>> specifically we lose the V_MAY_DEF for SFT.3_20.
> >>
>
On Apr 8, 2005, at 1:26 PM, Devang Patel wrote:
On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
When we rescan the operands, we get a different set of V_MAY_DEFS,
specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying sub
On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> In the interest of brevity, I'm just going to point out the
> problematical store from the .ifcvt dump:
>
>
> # x_16 = V_MAY_DEF ;
> # SFT.3_20 = V_MAY_DEF ;
> *D.1470_8 = D.1472_11;
>
> Which gets vectorized and appears like this in
On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
When we rescan the operands, we get a different set of V_MAY_DEFS,
specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying subvars to the new vectorizer variable too.
At leas
On Fri, Apr 08, 2005 at 10:11:33AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 06:58:54PM +0200, Jakub Jelinek wrote:
> > See middle-end/20794, there is discussion about declaring this
> > invalid. When a type with size that is not an integral multiple
> > of alignment (e.g. smaller size than
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> > There's a rather annoying bug in the vectorizer which can cause us to
> > have SSA_NAMEs which are used, but never defined.
> >
> > Consider this testcase compiled with -msse2 -ftree-vectorize:
> >
> > typedef char achar __attrib
On Fri, 2005-04-08 at 18:58 +0200, Jakub Jelinek wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> > There's a rather annoying bug in the vectorizer which can cause us to
> > have SSA_NAMEs which are used, but never defined.
> >
> > Consider this testcase compiled with -mss
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > specifically we lose the V_MAY_DEF for SFT.3_20.
>
> Why?
>
> It should be copying subvars to the new vectorizer variable too.
> At least, i believe i added that.
Whe
> When we rescan the operands, we get a different set of V_MAY_DEFS,
> specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying subvars to the new vectorizer variable too.
At least, i believe i added that.
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> There's a rather annoying bug in the vectorizer which can cause us to
> have SSA_NAMEs which are used, but never defined.
>
> Consider this testcase compiled with -msse2 -ftree-vectorize:
>
> typedef char achar __attribute__ ((__ali
There's a rather annoying bug in the vectorizer which can cause us to
have SSA_NAMEs which are used, but never defined.
Consider this testcase compiled with -msse2 -ftree-vectorize:
typedef char achar __attribute__ ((__aligned__(16)));
int main1 ()
{
struct {
achar *p;
achar *q;
} s;
28 matches
Mail list logo
