Eric Botcazou ebotca...@adacore.com 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
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 marcus.shawcr...@gmail.com writes:
On 14 January 2015
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 Botcazou
On 14 January 2015 at 07:35, Jeff Law l...@redhat.com 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
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
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
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
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 ebotca...@adacore.com writes:
Please be more specific though. If you don't think the patch is correct,
what do you think the
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
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 ebotca...@adacore.com 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.
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 ebotca...@adacore.com 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
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 since
[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
Alan Hayward alan.hayw...@arm.com 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
On 02/12/2014 12:36, Alan Hayward alan.hayw...@arm.com wrote:
On 21/11/2014 14:08, Alan Hayward alan.hayw...@arm.com wrote:
On 14/11/2014 16:48, Alan Hayward alan.hayw...@arm.com 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
On 10 December 2014 at 09:51, Alan Hayward alan.hayw...@arm.com 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
18 matches
Mail list logo
