On Thursday 26 December 2013, Gopalasubramanian, Ganesh wrote:
> Hi,
>
> >> (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and
> >> AMDFAM15H_BDVER3.
>
> As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead
> of using BOBCAT or JAGUAR. Attached patch
> I'm sorry I didn't notice previous conversation. Please install ASAP.
Thanks Uros! Committed to revision 206210.
- Ganesh
On Thu, Dec 26, 2013 at 7:28 AM, Gopalasubramanian, Ganesh
wrote:
>>> (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and
>>> AMDFAM15H_BDVER3.
>
> As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead
> of using BOBCAT or JAGUAR.
> Attached patch doe
Hi,
>> (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and
>> AMDFAM15H_BDVER3.
As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead of
using BOBCAT or JAGUAR.
Attached patch does the changes.
Regards
Ganesh
NameChange.patch
Description: NameChang
On Wed, Dec 25, 2013 at 3:09 PM, H.J. Lu wrote:
> On Wed, Dec 25, 2013 at 2:26 PM, Uros Bizjak wrote:
>> On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen
>> wrote:
>>> On Wednesday 25 December 2013, Uros Bizjak wrote:
On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen
w
On Wed, Dec 25, 2013 at 2:26 PM, Uros Bizjak wrote:
> On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen
> wrote:
>> On Wednesday 25 December 2013, Uros Bizjak wrote:
>>> On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen
>>>
>>> wrote:
>>> >> Will libgcc/config/i386/cpuinfo.c update be
On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen
wrote:
> On Wednesday 25 December 2013, Uros Bizjak wrote:
>> On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen
>>
>> wrote:
>> >> Will libgcc/config/i386/cpuinfo.c update be a separate patch?
>> >> Should we use a single definition for
On Wednesday 25 December 2013, Uros Bizjak wrote:
> On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen
>
> wrote:
> >> Will libgcc/config/i386/cpuinfo.c update be a separate patch?
> >> Should we use a single definition for both i386.c and libgcc?
> >
> > Currently they need to be in the sam
On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen
wrote:
>> Will libgcc/config/i386/cpuinfo.c update be a separate patch?
>> Should we use a single definition for both i386.c and libgcc?
>
> Currently they need to be in the same patch. But yes, moving the definition
> out to a common header
On Tuesday 24 December 2013, H.J. Lu wrote:
>
> Will libgcc/config/i386/cpuinfo.c update be a separate patch?
> Should we use a single definition for both i386.c and libgcc?
Currently they need to be in the same patch. But yes, moving the definition
out to a common header would probably be a goo
On Tue, Dec 24, 2013 at 6:38 AM, Allan Sandfeld Jensen
wrote:
> On Monday 23 December 2013, H.J. Lu wrote:
>>
>> If you use
>>
>> {"corei7-avx", M_INTEL_COREI7_SANYBRIDGE},
>> {"core-avx2", M_INTEL_COREI7_HASWELL},
>> will it cause any problems? When there are both
>>
> Actually I seems I don't n
On Monday 23 December 2013, H.J. Lu wrote:
>
> If you use
>
> {"corei7-avx", M_INTEL_COREI7_SANYBRIDGE},
> {"core-avx2", M_INTEL_COREI7_HASWELL},
>
> will it cause any problems? When there are both
>
Actually I seems I don't need these definitions any more after your clean-up
of Intel archite
On Mon, Dec 23, 2013 at 10:33 AM, Allan Sandfeld Jensen
wrote:
> On Monday 23 December 2013, H.J. Lu wrote:
>> On Mon, Dec 23, 2013 at 8:57 AM, Allan Sandfeld Jensen
>>
>> wrote:
>> > On Monday 23 December 2013, Allan Sandfeld Jensen wrote:
>> >> On Monday 23 December 2013, H.J. Lu wrote:
>> >> >
On Monday 23 December 2013, H.J. Lu wrote:
> On Mon, Dec 23, 2013 at 8:57 AM, Allan Sandfeld Jensen
>
> wrote:
> > On Monday 23 December 2013, Allan Sandfeld Jensen wrote:
> >> On Monday 23 December 2013, H.J. Lu wrote:
> >> > On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote:
On Mon, Dec 23, 2013 at 8:57 AM, Allan Sandfeld Jensen
wrote:
> On Monday 23 December 2013, Allan Sandfeld Jensen wrote:
>> On Monday 23 December 2013, H.J. Lu wrote:
>> > On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote:
>> > > On Thursday 19 December 2013, Gopalasubramanian,
On Monday 23 December 2013, Allan Sandfeld Jensen wrote:
> On Monday 23 December 2013, H.J. Lu wrote:
> > On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote:
> > > On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > > > > Sorry, I must have been looking at an older
On Monday 23 December 2013, H.J. Lu wrote:
> On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote:
> > On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > > > Sorry, I must have been looking at an older version, but as I said I
> > > > already did enable it in the la
On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote:
> On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > > Sorry, I must have been looking at an older version, but as I said I
> > > already did enable it in the latest patch. (see
> > > http://gcc.gnu.org/ml/gcc-pa
Hi!
On Thu, Dec 19, 2013 at 10:13:17AM +, Gopalasubramanian, Ganesh wrote:
> @@ -30044,25 +30053,49 @@
> break;
> case PROCESSOR_COREI7_AVX:
>arg_str = "corei7-avx";
> - priority = P_PROC_SSE4_2;
> + priority = P_PROC_AVX;
>
On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > Sorry, I must have been looking at an older version, but as I said I
> > already did enable it in the latest patch. (see
> > http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01577.html )
>
> Sorry for causing another revision but we wo
> Sorry, I must have been looking at an older version, but as I said I already
> did enable it in the latest patch. (see
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01577.html )
Sorry for causing another revision but we would like to stick with "btver1" and
"btver2" rather than "BOBCAT" or "
On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > Yes, I changed that in the last patch, though I consider it momentarily
> > problematic because you do not yet enable AVX with march=btver2 (AVX
> > versions would currently be better than btver2 versions for a btver2
> > arch), but
> Yes, I changed that in the last patch, though I consider it momentarily
> problematic because you do not yet enable AVX with march=btver2 (AVX versions
> would currently be better than btver2 versions for a btver2 arch), but expect
march=btver2 will be fixed soon.
The " processor_alias_table"
On Wednesday 18 December 2013, Gopalasubramanian, Ganesh wrote:
> Ping!
>
> "Gopalasubramanian, Ganesh" wrote:
> > Yes, I figured that was the original idea behind it, but the final family
> > of the jaguar processors seems to have become 16h instead of 14h
> > (bobcat) at some point.
>
> Yes. I
On Wed, Dec 18, 2013 at 4:38 PM, Gopalasubramanian, Ganesh
wrote:
>
> Ping!
>
> "Gopalasubramanian, Ganesh" wrote:
>
>
>> Yes, I figured that was the original idea behind it, but the final family of
>> the jaguar processors seems to have become 16h instead of 14h (bobcat) at
>> some point.
>
>
Ping!
"Gopalasubramanian, Ganesh" wrote:
> Yes, I figured that was the original idea behind it, but the final family of
> the jaguar processors seems to have become 16h instead of 14h (bobcat) at
> some point.
Yes. It is amdfam16h. I was supposed to pass on some comments on the patch.
1. Am
On Wed, Dec 18, 2013 at 1:57 PM, Allan Sandfeld Jensen
wrote:
> Update patch. Solved __attribute((target("arch=corei7-avx"))) by defining
> proper architectures for the recent Intel families instead of renaming
> submodels.
@@ -30922,9 +30955,13 @@
F_SSE2,
F_SSE3,
F_SSSE3,
+F_S
Update patch. Solved __attribute((target("arch=corei7-avx"))) by defining
proper architectures for the recent Intel families instead of renaming
submodels.
I am thinking the patch is starting to touch a bit many different details,
perhaps it should be split up, or is it good as is?
Regards
`A
On Tuesday 17 December 2013, Allan Sandfeld Jensen wrote:
> On Monday 16 December 2013, Uros Bizjak wrote:
> > On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak wrote:
> > > On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
> > >
> > > wrote:
> > >> Hi again
> > >>
> > >> On Wednesday 11 Decem
On Monday 16 December 2013, Uros Bizjak wrote:
> On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak wrote:
> > On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
> >
> > wrote:
> >> Hi again
> >>
> >> On Wednesday 11 December 2013, Uros Bizjak wrote:
> >>> Hello!
> >>>
> >>> > PR gcc/59422
> >>
> Yes, I figured that was the original idea behind it, but the final family of
> the jaguar processors seems to have become 16h instead of 14h (bobcat) at
> some point.
Yes. It is amdfam16h. I was supposed to pass on some comments on the patch.
1. Amdfam16h for Jaguar.
2. For Jaguar, the priorit
On Monday 16 December 2013, Gopalasubramanian, Ganesh wrote:
> > Btw, I couldn't find anything that corresponds to gcc's btver2 arch. Is
> > that an old term for what has become the Jaguar architecture?
>
> Yes, "btver2" = "jaguar". We have the name as per its family name (i.e,
> bobcat family) in
mes "bdver2" = "piledriver", "bdver3" = "steamroller"
as per their family (bulldozer) name.
Regards
Ganesh
-Original Message-
From: Allan Sandfeld Jensen [mailto:carew...@gmail.com]
Sent: Monday, December 16, 2013 12:25 AM
To: Uros Bizjak
Cc: gcc-pa
On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak wrote:
> On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
> wrote:
>
>> Hi again
>> On Wednesday 11 December 2013, Uros Bizjak wrote:
>>> Hello!
>>>
>>> > PR gcc/59422
>>> >
>>> > This patch extends the supported targets for function multi versi
On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
wrote:
> Hi again
> On Wednesday 11 December 2013, Uros Bizjak wrote:
>> Hello!
>>
>> > PR gcc/59422
>> >
>> > This patch extends the supported targets for function multi versiong to
>> > also include Haswell, Silvermont, and the most recent
Patch updated to keep libgcc enums backwards compatible.
`Allan
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 205984)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-12-14 Allan Sandfeld Jensen
+
+PR gcc/59422
Hi again
On Wednesday 11 December 2013, Uros Bizjak wrote:
> Hello!
>
> > PR gcc/59422
> >
> > This patch extends the supported targets for function multi versiong to
> > also include Haswell, Silvermont, and the most recent AMD models. It
> > also prioritizes AVX2 versions over AMD specific pre-
Hello!
> PR gcc/59422
>
> This patch extends the supported targets for function multi versiong to also
> include Haswell, Silvermont, and the most recent AMD models. It also
> prioritizes AVX2 versions over AMD specific pre-AVX2 versions.
Please add a ChangeLog entry and attach the complete patch
PR gcc/59422
This patch extends the supported targets for function multi versiong to also
include Haswell, Silvermont, and the most recent AMD models. It also
prioritizes AVX2 versions over AMD specific pre-AVX2 versions.
39 matches
Mail list logo
