On 7/21/16 3:26 AM, Alan Modra wrote:
On Wed, Jul 20, 2016 at 08:51:21PM -0500, Peter Bergner wrote:
This still doesn't answer David's question about what will happen if
we generate this pattern (or one of the older VSX reg+reg patterns)
when we are NOT using -mno-vsx. In those cases, quad_addr
On Wed, Jul 20, 2016 at 08:51:21PM -0500, Peter Bergner wrote:
> This still doesn't answer David's question about what will happen if
> we generate this pattern (or one of the older VSX reg+reg patterns)
> when we are NOT using -mno-vsx. In those cases, quad_address_p and
> mode_supports_vsx_dform
On 7/12/16 8:48 AM, Alan Modra wrote:
On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
The second time around, get_secondary_mem should reuse the
same stack slot it already allocated, and the elimination
offsets should already be set to accommodate that stack slot,
which means the
On Thu, Jul 14, 2016 at 12:14:10PM +0930, Alan Modra wrote:
> The following has now been bootstrapped and regression tested on
> powerpc64le-linux. OK for mainline?
>
> * gcc/config/rs6000/altivec.md (altivec_mov): Disparage
> gpr alternatives. Correct '*' placement on Y,r alternativ
On Thu, Jul 14, 2016 at 12:14:10PM +0930, Alan Modra wrote:
> (Which is a bug, since the advent of multi-char constraints, and
> potentially affects us with our use of constraint strings like "?*wb".)
On looking into this, I see it is just a documentation bug.
--
Alan Modra
Australia Development
On Wed, Jul 13, 2016 at 06:46:22AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 13, 2016 at 02:57:01PM +0930, Alan Modra wrote:
> > This is what I've bootstrapped and regression tested on
> > powerpc64le-linux. I'm using Peter's testcases from this thread
> > rather than the one in the original
On Wed, Jul 13, 2016 at 02:57:01PM +0930, Alan Modra wrote:
> This is what I've bootstrapped and regression tested on
> powerpc64le-linux. I'm using Peter's testcases from this thread
> rather than the one in the original patch submission, because that one
> relies on -O0 not reducing the function
This is what I've bootstrapped and regression tested on
powerpc64le-linux. I'm using Peter's testcases from this thread
rather than the one in the original patch submission, because that one
relies on -O0 not reducing the function down to a nop. OK to apply?
PR target/71733
gcc/
On Tue, Jul 12, 2016 at 04:17:23PM +0200, Ulrich Weigand wrote:
> Alan Modra wrote:
> > The problem now is that this passes rs6000_legitimate_address_p due to
> > mode_supports_vsx_dform_quad and quad_address_p being true. That
> > doesn't seem correct for -mno-vsx.
>
> Hmm, I see in rs6000_optio
Alan Modra wrote:
> On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
> > The second time around, get_secondary_mem should reuse the
> > same stack slot it already allocated, and the elimination
> > offsets should already be set to accommodate that stack slot,
> > which means the seco
On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
> The second time around, get_secondary_mem should reuse the
> same stack slot it already allocated, and the elimination
> offsets should already be set to accommodate that stack slot,
> which means the second time around, the correct
Alan Modra wrote:
> On Mon, Jul 11, 2016 at 03:26:46PM +0200, Ulrich Weigand wrote:
> > However, there still seems to be another underlying problem: reload
> > should never generate invalid instructions. (Playing with '?' to
> > fix *inefficient* instructions is fine, but we shouldn't rely on '?'
On Mon, Jul 11, 2016 at 03:26:46PM +0200, Ulrich Weigand wrote:
> However, there still seems to be another underlying problem: reload
> should never generate invalid instructions. (Playing with '?' to
> fix *inefficient* instructions is fine, but we shouldn't rely on '?'
> to fix *invalid* instruc
Alan Modra wrote:
> The reason this fails is that no alternative in altivec_mov
> exactly matches. Ideally reload would choose the Z,v alternative
> (cost 9) and you'd get an address reload for the mem to make it match
> the "Z" constraint. Instead reload chooses the Y,r alternative (cost
> 8) as
On Mon, Jul 11, 2016 at 04:07:11PM +0930, Alan Modra wrote:
> I believe all the r alternatives in altivec_mov should be
> disparaged with "?".
That certainly makes sense.
Okay for trunk if tested (also test with LRA, if you can). Thanks!
Segher
On Sat, Jul 09, 2016 at 10:26:55AM -0500, Peter Bergner wrote:
> The problem occurs when we have an altivec store, which is what the original
> test case had:
>
> bergner@genoa:~/gcc/BUGS/sawdey/altivec$ cat vec_store.i
> typedef __attribute__((altivec(vector__))) __attribute__((aligned(16)))
> u
On 7/6/16 12:53 PM, David Edelsohn wrote:
> On Tue, Jul 5, 2016 at 10:26 PM, Peter Bergner wrote:
>> The following patch fixes a bug where we do not disable POWER9 vector dform
>> addressing when we compile for POWER9 but without VSX support. This
>> manifested
>> itself with us trying to use df
On 7/6/16 6:29 PM, Michael Meissner wrote:
On Wed, Jul 06, 2016 at 05:01:38PM -0500, Peter Bergner wrote:
I had thought about adding the dform scalar flag, but it was already
correctly disabled and I wasn't sure whether we could have the p9
dform scalar without the vector part. Probably not, so
On Wed, Jul 06, 2016 at 05:01:38PM -0500, Peter Bergner wrote:
> On 7/6/16 2:19 PM, Michael Meissner wrote:
> >On Tue, Jul 05, 2016 at 09:26:50PM -0500, Peter Bergner wrote:
> >>- rs6000_isa_flags &= ~OPTION_MASK_P9_VECTOR;
> >>+ rs6000_isa_flags &= ~(OPTION_MASK_P9_VECTOR
> >>+
On 7/6/16 2:19 PM, Michael Meissner wrote:
On Tue, Jul 05, 2016 at 09:26:50PM -0500, Peter Bergner wrote:
- rs6000_isa_flags &= ~OPTION_MASK_P9_VECTOR;
+ rs6000_isa_flags &= ~(OPTION_MASK_P9_VECTOR
+ | OPTION_MASK_P9_DFORM_VECTOR);
}
Note, this should b
On Tue, Jul 05, 2016 at 09:26:50PM -0500, Peter Bergner wrote:
> The following patch fixes a bug where we do not disable POWER9 vector dform
> addressing when we compile for POWER9 but without VSX support. This
> manifested
> itself with us trying to use dform addressing with altivec loads/stores
On 7/6/16 12:53 PM, David Edelsohn wrote:
On Tue, Jul 5, 2016 at 10:26 PM, Peter Bergner wrote:
The following patch fixes a bug where we do not disable POWER9 vector dform
addressing when we compile for POWER9 but without VSX support. This manifested
itself with us trying to use dform addressi
On Tue, Jul 5, 2016 at 10:26 PM, Peter Bergner wrote:
> The following patch fixes a bug where we do not disable POWER9 vector dform
> addressing when we compile for POWER9 but without VSX support. This
> manifested
> itself with us trying to use dform addressing with altivec loads/stores
> which
The following patch fixes a bug where we do not disable POWER9 vector dform
addressing when we compile for POWER9 but without VSX support. This manifested
itself with us trying to use dform addressing with altivec loads/stores
which is illegal, leading to an ICE.
This has bootstrapped and regtest
24 matches
Mail list logo
