On 18 August 2014 17:50, Alan Lawrence alan.lawre...@arm.com wrote:
Well, you're right that it could be. So I presented the wrong justification.
Clearly we would benefit from some better cost infrastructure here, ideally
that is expressive, taken into account at all appropriate stages of the
Well, you're right that it could be. So I presented the wrong justification.
Clearly we would benefit from some better cost infrastructure here, ideally that
is expressive, taken into account at all appropriate stages of the compiler, and
tunable per core. I imagine that steps (patches)
On Tue, Aug 12, 2014 at 04:53:38PM +0100, pins...@gmail.com wrote:
On Aug 12, 2014, at 7:40 AM, Alan Lawrence alan.lawre...@arm.com wrote:
(It is no more expensive.)
Yes on some processors it could be.
Haven't we been here before [1]?
This disparaging mechanism is still not going
On 2014-08-13, 4:36 AM, James Greenhalgh wrote:
On Tue, Aug 12, 2014 at 04:53:38PM +0100, pins...@gmail.com wrote:
On Aug 12, 2014, at 7:40 AM, Alan Lawrence alan.lawre...@arm.com wrote:
(It is no more expensive.)
Yes on some processors it could be.
Haven't we been here before [1]?
(It is no more expensive.)
gcc/ChangeLog:
* config/aarch64/aarch64.md (subdi3, adddi3_aarch64): Don't penalize
SIMD reg variant.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index
On Aug 12, 2014, at 7:40 AM, Alan Lawrence alan.lawre...@arm.com wrote:
(It is no more expensive.)
Yes on some processors it could be.
Thanks,
Andrew
gcc/ChangeLog:
* config/aarch64/aarch64.md (subdi3, adddi3_aarch64): Don't penalize
SIMD reg variant.
diff --git
