On Mon, Feb 15, 2016 at 4:24 PM, Alan Modra wrote:
> On Mon, Feb 15, 2016 at 06:42:35AM -0800, David Edelsohn wrote:
>> Is there still an issue with the constraints used for movdi_internal64?
>
> Yes and no. No because we shouldn't be attempting DI moves between vsx
> regs and gprs. Yes because
On Mon, Feb 15, 2016 at 06:42:35AM -0800, David Edelsohn wrote:
> Is there still an issue with the constraints used for movdi_internal64?
Yes and no. No because we shouldn't be attempting DI moves between vsx
regs and gprs. Yes because we ought to allow DImode in vsx regs, but
fixing that is lik
On Mon, Feb 15, 2016 at 4:36 AM, Alan Modra wrote:
> On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote:
>> > On Fri, Feb 12, 2016 at 08:54:19AM +1030, Alan Modra wrote:
>> > > Another concern I had about this, besides using %L in asm output (what
>> > > forces TFmode to use just fprs?
Alan Modra wrote:
> On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote:
> > Right. It's a bit unfortunate that we can't just use IFmode
> > unconditionally,
> > but it seems rs6000_scalar_mode_supported_p (IFmode) may return false, and
> > then we probably shouldn't be using it.
>
>
On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote:
> > On Fri, Feb 12, 2016 at 08:54:19AM +1030, Alan Modra wrote:
> > > Another concern I had about this, besides using %L in asm output (what
> > > forces TFmode to use just fprs?), is what happens when we're using
> > > IEEE 128-bit fl
(Replying to multiple messages at once ...)
Michael Meissner wrote:
> At the present time, we do not allow DImode to go into Altivec
> registers. Mostly it was due to reload complications in the power8 time frame,
> where we didn't have d-form addressing for the Altivec registers and
> interferen
On Thu, Feb 11, 2016 at 10:38 AM, Ulrich Weigand wrote:
> David Edelsohn wrote:
>> On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
>> > This is PR68973 part 2, the failure of a boost test, caused by a
>> > splitter emitting an invalid move in reload_vsx_from_gprsf:
>> > emit_move_insn (op0_d
On Fri, Feb 12, 2016 at 08:54:19AM +1030, Alan Modra wrote:
> On Thu, Feb 11, 2016 at 04:55:58PM -0500, Michael Meissner wrote:
> > This is one of the cases I wished the reload support had the ability to
> > allocate 2 scratch temporaries instead of 1. As I said in my other message,
> > TFmode was
On Thu, Feb 11, 2016 at 04:55:58PM -0500, Michael Meissner wrote:
> This is one of the cases I wished the reload support had the ability to
> allocate 2 scratch temporaries instead of 1. As I said in my other message,
> TFmode was a hack to get two registers to use.
Another concern I had about th
On Thu, Feb 11, 2016 at 07:38:15PM +0100, Ulrich Weigand wrote:
> For the most part, this patch doesn't really change anything in the
> interaction with reload as far as I can see. The changes introduced
> by the patch do make sense to me. In particular, replacing the two
> patterns p8_mtvsrd_1 a
On Thu, Feb 11, 2016 at 09:34:29AM -0800, David Edelsohn wrote:
> On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
> > This is PR68973 part 2, the failure of a boost test, caused by a
> > splitter emitting an invalid move in reload_vsx_from_gprsf:
> > emit_move_insn (op0_di, op2);
> >
> > op0
David Edelsohn wrote:
> On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
> > This is PR68973 part 2, the failure of a boost test, caused by a
> > splitter emitting an invalid move in reload_vsx_from_gprsf:
> > emit_move_insn (op0_di, op2);
> >
> > op0 can be any vsx reg, but the mtvsrd destina
On Thu, Feb 11, 2016 at 6:04 AM, Alan Modra wrote:
> This is PR68973 part 2, the failure of a boost test, caused by a
> splitter emitting an invalid move in reload_vsx_from_gprsf:
> emit_move_insn (op0_di, op2);
>
> op0 can be any vsx reg, but the mtvsrd destination constraint in
> movdi_interna
This is PR68973 part 2, the failure of a boost test, caused by a
splitter emitting an invalid move in reload_vsx_from_gprsf:
emit_move_insn (op0_di, op2);
op0 can be any vsx reg, but the mtvsrd destination constraint in
movdi_internal64 is "wj", which only allows fp regs. I'm not sure why
we ha
14 matches
Mail list logo
