On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency
with all the other architectures. Note e.g. x86_64 dynamic linker
is /lib64/ld-linux-x86-64.so.2,
On Apr 11, 2012, at 7:22 PM, Michael Hope wrote:
> My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> * is similar to /lib/ld-x86-64.so.2
> * keeps the libraries and loader in the same directory
> * doesn't invent a new /libhf directory
> * is easier to implement in GLIBC
> * is architecture
The Linaro Toolchain Working Group is pleased to announce the 2012.04
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.04 is the first release in the 4.7 series. Based
off the latest GCC 4.7.0+svn186061 release, it includes performance
improvements especially around 64 bit op
Em 11 de abril de 2012 22:39, Michael Hope escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> :
>> Em 11 de abril de 2012 21:16, Michael Hope
>> escreveu:
>>> 2012/4/12 Paulo César Pereira de Andrade
>>> :
Em 11 de abril de 2012 20:22, Michael Hope
escreveu:
> On 12 April 201
2012/4/12 Paulo César Pereira de Andrade
:
> Em 11 de abril de 2012 21:16, Michael Hope escreveu:
>> 2012/4/12 Paulo César Pereira de Andrade
>> :
>>> Em 11 de abril de 2012 20:22, Michael Hope
>>> escreveu:
On 12 April 2012 10:38, Steve McIntyre wrote:
> On Wed, Apr 11, 2012 at 02:06:
On Wednesday 11 April 2012 03:37:56 Konstantinos Margaritis wrote:
> On Tue, 10 Apr 2012 23:01:47 -0400 Mike Frysinger wrote:
> > one of the downsides of traveling down a path and upstreaming as an after
> > thought
>
> You didn't really follow arm hardfloat progress in the past 2 years, did
> you
On 12 April 2012 12:38, Wookey wrote:
> +++ Michael Hope [2012-04-12 12:16 +1200]:
>> 2012/4/12 Paulo César Pereira de Andrade
>> :
>
>> >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>> > Sorry for more bikeshedding,
>> > /lib/ld-linux-armv7hl.so.3
>> I'd rather drop the '
Em 11 de abril de 2012 21:16, Michael Hope escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> :
>> Em 11 de abril de 2012 20:22, Michael Hope
>> escreveu:
>>> On 12 April 2012 10:38, Steve McIntyre wrote:
On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>
>And he
On 04/11/2012 05:16 PM, Michael Hope wrote:
> 2012/4/12 Paulo César Pereira de Andrade
>> /lib/ld-linux-armv7hl.so.3
>
> This includes the ABI (h), adds the endianess (l), and implies a
> architecture level (v7). The name for the most common configurations
> should be as short as possible so I'd
On Wednesday 11 April 2012 11:25:55 Paulo César Pereira de Andrade wrote:
> Probably beating a dead cow, but, the major problem with sysroots
> would be the triplet name?
>
> E.g, in any architecture:
>
> /arm-linux-gnueabi/sysroot-contents-here
it isn't really about having a sysroot the too
On Wednesday 11 April 2012 05:47:29 Steve McIntyre wrote:
> On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote:
> >On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
> >> * /lib/ld-linux-$triplet.so.3
> >> - could work fine, so long as we can agree on triplets
> >
> >kind of
+++ Michael Hope [2012-04-12 12:16 +1200]:
> 2012/4/12 Paulo César Pereira de Andrade
> :
> >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> > Sorry for more bikeshedding,
> > /lib/ld-linux-armv7hl.so.3
> I'd rather drop the 'l'
We've already had the GNU triplet-name argu
2012/4/12 Paulo César Pereira de Andrade
:
> Em 11 de abril de 2012 20:22, Michael Hope escreveu:
>> On 12 April 2012 10:38, Steve McIntyre wrote:
>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
And here's the details as promised.
I've started a wiki page at
Em 11 de abril de 2012 20:22, Michael Hope escreveu:
> On 12 April 2012 10:38, Steve McIntyre wrote:
>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>
>>>And here's the details as promised.
>>>
>>>I've started a wiki page at
>>>
>>>https://wiki.linaro.org/OfficeofCTO/HardFloa
"Singh, Ravi Kumar (Ravi)" wrote on 11.04.2012
17:50:53:
> If I disable extra transformations as suggested by you my cycles
> increase to 38xx in comparison to -O2 25xx
Sorry, I misremembered the flag spelling. It should read:
-ftree-vectorize -fno-tree-loop-if-convert --param max-stores-to
Mans Rullgard wrote on 11.04.2012 18:21:46:
> On 11 April 2012 16:16, Ulrich Weigand wrote:
> > "Singh, Ravi Kumar (Ravi)" wrote:
> >
> >> Are there any pragmas for selectively disabling (in one chunk of
> >> code) the vectorization, when its enabled globally.
> >
> > No, there are not (just lik
Em 11 de abril de 2012 10:04, Steve McIntyre
escreveu:
> On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
>>On 04/10/2012 04:42 AM, Steve McIntyre wrote:
>>>It's one of the things we're trying to achieve with multi-arch. We can
>>>support mixed-ABI, mixed-OS, mixed-architecture environmen
On 12 April 2012 10:38, Steve McIntyre wrote:
> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>
>>And here's the details as promised.
>>
>>I've started a wiki page at
>>
>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>>with a strawman agenda for now, an
Hi Steve,
Please ensure Jakub on our end is involved in the meeting. We discussed
compromise solutions that are acceptable to him and Dennis today and I
would like him to be involved in the discussion. He is on CET, but
cannot make calls after 10pm UTC. I prefer that we try to have this on
Friday,
On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>
>And here's the details as promised.
>
>I've started a wiki page at
>
>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
>with a strawman agenda for now, and a Doodle poll at
>
>http://www.doodle.com/93bitkqeb7a
On 11 April 2012 22:05, Ramana Radhakrishnan
wrote:
> On 11 April 2012 17:21, Mans Rullgard wrote:
>> On 11 April 2012 16:16, Ulrich Weigand wrote:
>>> "Singh, Ravi Kumar (Ravi)" wrote:
>>>
Are there any pragmas for selectively disabling (in one chunk of
code) the vectorization, when
On 11 April 2012 17:21, Mans Rullgard wrote:
> On 11 April 2012 16:16, Ulrich Weigand wrote:
>> "Singh, Ravi Kumar (Ravi)" wrote:
>>
>>> Are there any pragmas for selectively disabling (in one chunk of
>>> code) the vectorization, when its enabled globally.
>>
>> No, there are not (just like for
On 12 April 2012 04:21, Mans Rullgard wrote:
> On 11 April 2012 16:16, Ulrich Weigand wrote:
>> "Singh, Ravi Kumar (Ravi)" wrote:
>>
>>> Are there any pragmas for selectively disabling (in one chunk of
>>> code) the vectorization, when its enabled globally.
>>
>> No, there are not (just like for
On 11 April 2012 16:16, Ulrich Weigand wrote:
> "Singh, Ravi Kumar (Ravi)" wrote:
>
>> Are there any pragmas for selectively disabling (in one chunk of
>> code) the vectorization, when its enabled globally.
>
> No, there are not (just like for all optimization settings).
Are you saying __attribu
Ulrich,
If I disable extra transformations as suggested by you my cycles increase to
38xx in comparison to -O2 25xx
Regards
RKS
-Original Message-
From: Ulrich Weigand [mailto:ulrich.weig...@de.ibm.com]
Sent: Wednesday, April 11, 2012 10:15 AM
To: Singh, Ravi Kumar (Ravi)
Cc: linaro-t
"Singh, Ravi Kumar (Ravi)" wrote:
> None of the generated code contains the NEON instructions. Code
> generated with case 1 is taking 3000 cycles, and code generated by
> option 2 is taking 2500 cycles.
>
> Even if vectorization failed in case1, it should not generate more
> inefficient code than
"Singh, Ravi Kumar (Ravi)" wrote:
> Are there any pragmas for selectively disabling (in one chunk of
> code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
You'd have to place the chunk of code into a separate file
and build it with a
All,
In the below code, I tried few compiler options and got following observations:
1) arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a15 -mfpu=neon
-ftree-vectorizer-verbose=6 -ftree-vectorize
Compiler throws following info messages:
foo.c:16: note: not vectorized: unsupported use in stmt
All,
Are there any pragmas for selectively disabling (in one chunk of code) the
vectorization, when its enabled globally.
regards
Ravi Singh
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/l
On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
>On 04/10/2012 04:42 AM, Steve McIntyre wrote:
>>It's one of the things we're trying to achieve with multi-arch. We can
>>support mixed-ABI, mixed-OS, mixed-architecture environments cleanly
>>on one system, using a consistent set of package
On 04/10/2012 04:42 AM, Steve McIntyre wrote:
It's one of the things we're trying to achieve with multi-arch. We can
support mixed-ABI, mixed-OS, mixed-architecture environments cleanly
on one system, using a consistent set of packages for all. Setting up
a cross-compilation environment suddenly
On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote:
>On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
>> We understand that not everybody may want or see the need for this for
>> themselves. We *really* get that. But we want it to be possible for
>> *us* to do it, and an ultra-im
On Tue, 10 Apr 2012 23:01:47 -0400
Mike Frysinger wrote:
> one of the downsides of traveling down a path and upstreaming as an after
> thought
You didn't really follow arm hardfloat progress in the past 2 years, did you
(if you did you'd already be aware of attempts to get this thing upstreamed
33 matches
Mail list logo
