Eric Botcazou writes:
>> Seems like the thread might have died down, so just wanted to ping it.
>> As Marcus says, this is holding up other patches so it'd be good to get
>> something in soon. Would it be OK to commit the original patch or should
>> we wait?
>
> Yes, go ahead, but add a FIXME or
> Seems like the thread might have died down, so just wanted to ping it.
> As Marcus says, this is holding up other patches so it'd be good to get
> something in soon. Would it be OK to commit the original patch or should
> we wait?
Yes, go ahead, but add a FIXME or ??? comment.
--
Eric Botcazo
Seems like the thread might have died down, so just wanted to ping it.
As Marcus says, this is holding up other patches so it'd be good to get
something in soon. Would it be OK to commit the original patch or should
we wait?
Marcus Shawcroft writes:
> On 14 January 2015 at 07:35, Jeff Law wrote
On 14 January 2015 at 07:35, Jeff Law wrote:
> On 01/13/15 11:55, Eric Botcazou wrote:
>>
>>
>>> (1) we have a non-paradoxical subreg;
>>> (2) both (reg:ymode xregno) and (reg:xmode xregno) occupy full
>>> hard registers (no padding or unused upper bits);
>>> (3) (reg:ymode xregno) and (reg:x
On 01/13/15 11:55, Eric Botcazou wrote:
(1) we have a non-paradoxical subreg;
(2) both (reg:ymode xregno) and (reg:xmode xregno) occupy full
hard registers (no padding or unused upper bits);
(3) (reg:ymode xregno) and (reg:xmode xregno) store the same number
of bytes (X) in each const
On 01/10/15 06:05, Richard Sandiford wrote:
Sorry for the slow response. Jeff has approved the patch in the
meantime, but I didn't want to go ahead and apply it while there
was still disagreement...
Thanks. I didn't realize there was a disagreement when I approved.
Let's continue to hash this
> Sorry for the slow response. Jeff has approved the patch in the
> meantime, but I didn't want to go ahead and apply it while there
> was still disagreement...
I still think that it isn't appropriate to short-circuit the main computation
as the patch does, but I don't want to block it after Jef
Sorry for the slow response. Jeff has approved the patch in the
meantime, but I didn't want to go ahead and apply it while there
was still disagreement...
Eric Botcazou writes:
>> Please be more specific though. If you don't think the patch is correct,
>> what do you think the requirement shoul
On 12/12/14 04:07, Alan Hayward wrote:
[Cleaning this thread up to submit patch again, with better explanation]
This patch causes subreg_get_info() to exit early in the simple cases
where we are extracting a whole register from a multi register.
In aarch64 for Big Endian we were producing a sub
> Please be more specific though. If you don't think the patch is correct,
> what do you think the requirement should be and how should it be integrated
> into the existing checks?
Good question, but I have asked it first. :-)
So what are the new subregs that we want to accept here? Can someone
Eric Botcazou writes:
>> What do you think we should relax it to though? Obviously there's a balance
>> here between relaxing things enough and not relaxing them too far (so that
>> the EImode AArch64 thing I mentioned is still a noisy failure, for
>> example). ISTM the patch deals with the only
> What do you think we should relax it to though? Obviously there's a balance
> here between relaxing things enough and not relaxing them too far (so that
> the EImode AArch64 thing I mentioned is still a noisy failure, for
> example). ISTM the patch deals with the only significant case that is
>
Eric Botcazou writes:
>> FWIW I agree this is the right approach, although I can't approve it.
>> The assert above is guarding code that deals with a very general case,
>> including some unusual combinations, so I don't think it would be a
>> good idea to try to remove it entirely.
>
> Yes, but th
> FWIW I agree this is the right approach, although I can't approve it.
> The assert above is guarding code that deals with a very general case,
> including some unusual combinations, so I don't think it would be a
> good idea to try to remove it entirely.
Yes, but the patch is a bit of kludge sin
Alan Hayward writes:
> [Cleaning this thread up to submit patch again, with better explanation]
>
> This patch causes subreg_get_info() to exit early in the simple cases
> where we are extracting a whole register from a multi register.
>
> In aarch64 for Big Endian we were producing a subreg of a
[Cleaning this thread up to submit patch again, with better explanation]
This patch causes subreg_get_info() to exit early in the simple cases
where we are extracting a whole register from a multi register.
In aarch64 for Big Endian we were producing a subreg of a OImode (256bits)
from a CImode (
On 10 December 2014 at 09:51, Alan Hayward wrote:
This is a new version of my BE patch from a few weeks ago.
This is part 1 and covers rtlanal.c. The second part will be aarch64
specific.
When combined with the second patch, It fixes up movoi/ci/xi for Big
Endian, so that
On 02/12/2014 12:36, "Alan Hayward" wrote:
>
>On 21/11/2014 14:08, "Alan Hayward" wrote:
>
>>
>>On 14/11/2014 16:48, "Alan Hayward" wrote:
>>
>>>This is a new version of my BE patch from a few weeks ago.
>>>This is part 1 and covers rtlanal.c. The second part will be aarch64
>>>specific.
>>>
>
On 21/11/2014 14:08, "Alan Hayward" wrote:
>
>On 14/11/2014 16:48, "Alan Hayward" wrote:
>
>>This is a new version of my BE patch from a few weeks ago.
>>This is part 1 and covers rtlanal.c. The second part will be aarch64
>>specific.
>>
>>When combined with the second patch, It fixes up movoi/
On 14/11/2014 16:48, "Alan Hayward" wrote:
>This is a new version of my BE patch from a few weeks ago.
>This is part 1 and covers rtlanal.c. The second part will be aarch64
>specific.
>
>When combined with the second patch, It fixes up movoi/ci/xi for Big
>Endian, so that we end up with the lab
This is a new version of my BE patch from a few weeks ago.
This is part 1 and covers rtlanal.c. The second part will be aarch64
specific.
When combined with the second patch, It fixes up movoi/ci/xi for Big
Endian, so that we end up with the lab of a big-endian integer to be in
the low byte of the
21 matches
Mail list logo
