On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra wrote:
> Hi all,
>
> At the GNU Cauldron I was inspired by several interesting talks about
> improving
> GCC in various ways. While GCC has many great optimizations, a common theme is
> that its default settings are rather conservative. As a result
On 12 September 2017 at 23:58, Dave Gittins wrote:
> I confirmed this issue on x86_64 CentOS, and independently here:
> https://wandbox.org/permlink/ncWqA9Zu3YEofqri
>
> Also fails on gcc trunk.
>
> Possibly related to bug 81338 "stringstream remains empty after being
> moved into multiple times"?
On Tue, 2017-09-12 at 21:46 +0200, Eric Botcazou wrote:
> > In contrast to the existing scalar storage order support for structs, the
> > goal is to reverse the storage order for all memory operations to achieve
> > maximum compatibility with the behavior on big-endian systems, as far as
> > observ
On Tue, 2017-09-12 at 08:52 -0700, H.J. Lu wrote:
> Can you use __attribute__ ((scalar_storage_order)) in GCC 7?
To support existing large code bases, the goal is to reverse storage
order for all scalars, not just (selected) structs/unions. Also need to
support taking the address of a scalar field
> On Sep 13, 2017, at 5:51 AM, Jürg Billeter
> wrote:
>
> On Tue, 2017-09-12 at 08:52 -0700, H.J. Lu wrote:
>> Can you use __attribute__ ((scalar_storage_order)) in GCC 7?
>
> To support existing large code bases, the goal is to reverse storage
> order for all scalars, not just (selected) stru
On Jul 20 2017, Sebastian Huber wrote:
> Ok, so why do I get a "error: unrecognizable insn:"? How can I debug a
> message like this:
>
> (insn 12 11 13 2 (set (reg:CCFP 126)
> (compare:CCFP (reg:TF 123)
> (reg:TF 124))) "test-v0.i":5 -1
> (nil))
This is supposed to be ma
> Was this considered significantly more complex because of the need to
> discriminate between native and reverse order? Or do you expect similar
> complexity even if this is not required (see my comment below)?
The former.
> I don't. The idea is to reverse scalar storage order for the whole
> us
On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote:
>
>> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote:
>>
>> - https://rv8.io/bench#optimisation
>> - https://rv8.io/bench#executable-file-sizes
>>
>> -O2 is 98% perf of -O3 on x86-64
>> -Os is 81% perf of -O3 on x86-64
>>
>> -O2 saves 5% space
On Wed, Sep 13, 2017 at 9:43 AM, Janne Blomqvist
wrote:
> On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra
> wrote:
>> These are just a few ideas to start. What do people think? I'd welcome
>> discussion
>> and other proposals for similar improvements.
>
> What about the default behavior if no o
On Wed, 2017-09-13 at 13:08 +, paul.kon...@dell.com wrote:
> > On Sep 13, 2017, at 5:51 AM, Jürg Billeter
> > wrote:
> > To support existing large code bases, the goal is to reverse storage
> > order for all scalars, not just (selected) structs/unions. Also need to
> > support taking the addr
On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> On its own -O3 doesn't add much (some loop opts and slightly more
> aggressive inlining/unrolling), so whatever it does we
> should consider doing at -O2 eventually.
Well, -O3 adds vectorization, which we don't enable at -O2 by defa
On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek wrote:
> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> On its own -O3 doesn't add much (some loop opts and slightly more
>> aggressive inlining/unrolling), so whatever it does we
>> should consider doing at -O2 eventually.
>
> Wel
On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote:
> > On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote:
> >
> > Hi all,
> >
> > At the GNU Cauldron I was inspired by several interesting talks about
> > improving GCC in various ways. While GCC has many great optimizations, a
> >
On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> > On its own -O3 doesn't add much (some loop opts and slightly more
> > aggressive inlining/unrolling), so whatever it does we
> > should consider doing at -O2 even
> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek wrote:
> > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> >> On its own -O3 doesn't add much (some loop opts and slightly more
> >> aggressive inlining/unrolling), so whatever it does we
> >> should consider doing at -O2 eventuall
> On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote:
> >
> >> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote:
> >>
> >> - https://rv8.io/bench#optimisation
> >> - https://rv8.io/bench#executable-file-sizes
> >>
> >> -O2 is 98% perf of -O3 on x86-64
> >> -Os is 81% perf of -O3 on x86-64
> >>
>
On 12/09/17 16:57, Wilco Dijkstra wrote:
[...] As a result users are
required to enable several additional optimizations by hand to get good code.
Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
mentioned repeatedly) which GCC could/should do as well.
[...]
I'd welco
On September 13, 2017 5:35:11 PM GMT+02:00, Jan Hubicka wrote:
>> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek
>wrote:
>> > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> >> On its own -O3 doesn't add much (some loop opts and slightly more
>> >> aggressive inlining/unrolling
> >I don't see static profile prediction to be very useful here to find
> >"really
> >hot code" - neither in current implementation or future. The problem of
> >-O2 is that we kind of know that only 10% of code somewhere matters for
> >performance but we have no way to reliably identify it.
>
> It
On September 13, 2017 6:24:21 PM GMT+02:00, Jan Hubicka wrote:
>> >I don't see static profile prediction to be very useful here to find
>> >"really
>> >hot code" - neither in current implementation or future. The problem
>of
>> >-O2 is that we kind of know that only 10% of code somewhere matters
>
On 09/12/2017 02:32 AM, Jürg Billeter wrote:
To support applications that assume big-endian memory layout on little-
endian systems, I'm considering adding support for reversing the
storage order to GCC. In contrast to the existing scalar storage order
support for structs, the goal is to reverse
On Wed, 13 Sep 2017, Jim Wilson wrote:
> Intel has support for this in icc. It took about 5 years for a small team to
And allegedly has patents in this area.
--
Joseph S. Myers
jos...@codesourcery.com
Snapshot gcc-6-20170913 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170913/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
Jürg Billeter writes:
>
> I don't. The idea is to reverse scalar storage order for the whole
> userspace process and then add byte swapping to the Linux kernel when
> accessing userspace memory. This keeps userspace memory consistent
> with regards to endianness, which should lead to high compatib
> On 5 Sep 2017, at 9:35 AM, Michael Clark wrote:
>
>>
>> On 19 Aug 2017, at 4:10 AM, Richard Henderson wrote:
>>
>> On 08/17/2017 03:29 PM, Michael Clark wrote:
>>> hand coded x86 asm (no worse because the sar depends on the lea)
>>>
>>> sx5(int):
>>> shl edi, 27
>>> sar edi
> And there are lots of other problems, I don't have time to document them
> all, or even remember them all. Personally, I think you are better off
> trying to fix the application to make it more portable. Fixing the
> compiler is not a magic solution to the problem that is any easier than
> fixi
26 matches
Mail list logo
