On Fri, Sep 27, 2013 at 8:46 AM, H.J. Lu wrote:
>> So I would incline to be apply extra care on this flag and keep it for extra
>> release or two. Most of gcc.opensuse.org testing runs on these and adding
>> random branch mispredictions will trash them.
>>
>> At the related note, would would you
Jan Hubicka writes:
>
> I also added X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL to bobcat tuning, since it
> seems like obvious omision (after double checking in optimization manual) and
> droped X86_TUNE_FOUR_JUMP_LIMIT for buldozer cores.
When tuning for Intel SandyBridge+ it would be actually intere
On Fri, Sep 27, 2013 at 8:36 AM, Jan Hubicka wrote:
>> On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka wrote:
>> > Hi,
>> > this is second part of the generic tuning changes sanityzing the tuning
>> > flags.
>> > This patch again is supposed to deal with the "obvious" part only.
>> > I will send se
> On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka wrote:
> > Hi,
> > this is second part of the generic tuning changes sanityzing the tuning
> > flags.
> > This patch again is supposed to deal with the "obvious" part only.
> > I will send separate patch for more changes.
> >
> > The flags changed ag
On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka wrote:
> Hi,
> this is second part of the generic tuning changes sanityzing the tuning flags.
> This patch again is supposed to deal with the "obvious" part only.
> I will send separate patch for more changes.
>
> The flags changed agree on all CPUs con
Hi,
this is second part of the generic tuning changes sanityzing the tuning flags.
This patch again is supposed to deal with the "obvious" part only.
I will send separate patch for more changes.
The flags changed agree on all CPUs considered for generic (and their
optimization manuals) + amdfam10,
