On 18 August 2014 17:50, Alan Lawrence 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
> compiler, and tun
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) towards
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 wrote:
(It is no more expensive.)
Yes on some processors it could be.
Haven't we been here before [1]?
This disparaging mechanis
On Tue, Aug 12, 2014 at 04:53:38PM +0100, pins...@gmail.com wrote:
>
>
> > On Aug 12, 2014, at 7:40 AM, Alan Lawrence 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 to give what
> On Aug 12, 2014, at 7:40 AM, Alan Lawrence 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 a/gcc/config/aarch64/aa
(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 f8eb305140e7b0aed006b33f1724a90939e48316..0a8ca4bcc7941f912c8d42200b332
