On Thu, Aug 17, 2017 at 05:22:34PM +, paul.kon...@dell.com wrote:
> I think G-J said "... LRA focusses just comfortable, orthogonal targets"
> which is not quite the same thing.
>
> I'm a bit curious about that, since x86 is hardly "comfortable orthogonal".
> But if LRA is targeted only at
On Thu, Aug 17, 2017 at 12:36 PM, Bin.Cheng wrote:
> Your work will contribute to this and must be highly appreciated :)
>
I apologize for interjecting as I do not understand GCC internals very
well, but I appreciate all of the work that is contributed to GCC,
especially by individuals on their o
> On Aug 17, 2017, at 1:36 PM, Bin.Cheng wrote:
>
> On Thu, Aug 17, 2017 at 6:22 PM, wrote:
>>
>> ...
>> One of GCC's great strength is its support for many ISAs. Not all to the
>> same level of excellence, but there are many, and adding more is easy at
>> least for an initial basic level
On Thu, Aug 17, 2017 at 6:22 PM, wrote:
>
>> On Aug 17, 2017, at 11:22 AM, Oleg Endo wrote:
>>
>> On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote:
>>>
>>> LRA is easier to work with than old reload, and that makes it better
>>> maintainable.
>>>
>>> Making LRA handle everything reloa
> On Aug 17, 2017, at 11:22 AM, Oleg Endo wrote:
>
> On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote:
>>
>> LRA is easier to work with than old reload, and that makes it better
>> maintainable.
>>
>> Making LRA handle everything reload did is work, and someone needs to
>> do it.
>
On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote:
>
> LRA is easier to work with than old reload, and that makes it better
> maintainable.
>
> Making LRA handle everything reload did is work, and someone needs to
> do it.
>
> LRA probably needs a few more target hooks (a _few_) to gui
On Wed, Aug 16, 2017 at 11:23:27PM +0900, Oleg Endo wrote:
> > First of all, LRA cannot cope with cc0 (Yes, I know deprecating
> > cc0 is just to deprecate all non-LRA BEs). LRA asserts that
> > accessing the frame doesn't change condition code. LRA doesn't
> > provide replacement for LEGITIMITE_R
On Wed, Aug 16, 2017 at 03:53:24PM +0200, Georg-Johann Lay wrote:
> This means it's actually waste of time to work on these backends. The
> code will finally end up in the dustbin as cc0 backends are considered
> undesired ballast that has to be "jettisoned".
>
> "Deprecate all cc0" is just a nic
On 08/16/2017 08:14 AM, Eric Botcazou wrote:
>> Just the fact that the backends that get most attention and attract
>> most developers don't use cc0 doesn't mean cc0 is a useless device.
>
> Everything that can be done with cc0 can be done with the new representation,
> at least theoritically, al
On Wed, 2017-08-16 at 15:53 +0200, Georg-Johann Lay wrote:
>
> This means it's actually waste of time to work on these
> backends. The code will finally end up in the dustbin as cc0
> backends are considered undesired ballast that has to be
> "jettisoned".
>
> "Deprecate all cc0" is just a nice
> Just the fact that the backends that get most attention and attract
> most developers don't use cc0 doesn't mean cc0 is a useless device.
Everything that can be done with cc0 can be done with the new representation,
at least theoritically, although this can require more work.
> As far as cc0 i
On 31.07.2017 19:54, Jeff Law wrote:
On 07/31/2017 11:23 AM, Segher Boessenkool wrote:
On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote:
I could probably write a similar rant. This is the life of a "minority
target programmer". Most development efforts are being done with
primary tar
On 04/08/17 10:38, Claudiu Zissulescu wrote:
> Maybe better is to use the updated CsIbe repo from github
> https://github.com/szeged/csibe. I use it for ARC to track the code
> size.
>
Thanks for the link Claudiu. Personally I'll probably stick with the
existing code as I now have size data for
Maybe better is to use the updated CsIbe repo from github
https://github.com/szeged/csibe. I use it for ARC to track the code
size.
Cheers,
Claudiu
On Fri, Aug 4, 2017 at 11:12 AM, Richard Earnshaw
wrote:
> On 03/08/17 13:11, Steven Bosscher wrote:
>> On Mon, Jul 31, 2017 at 6:49 PM, Joel Sherri
On 03/08/17 13:11, Steven Bosscher wrote:
> On Mon, Jul 31, 2017 at 6:49 PM, Joel Sherrill wrote:
>
>>
>> Long ago, there was a code size regression tester for at least
>> ARM. Is that still around?
>
> There used to be autotesters from CSiBE. Something still appears to
> exist (http://www.csibe.
On Mon, Jul 31, 2017 at 6:49 PM, Joel Sherrill wrote:
>
> Long ago, there was a code size regression tester for at least
> ARM. Is that still around?
There used to be autotesters from CSiBE. Something still appears to
exist (http://www.csibe.org/old/) but the last time I tried to run the
benchmar
On Wed, Aug 2, 2017 at 3:54 PM, Segher Boessenkool
wrote:
> On Tue, Aug 01, 2017 at 01:50:14PM +0200, David Brown wrote:
>> I would not expect that to be good at all. With no optimisation (-O0),
>> gcc produces quite poor code - local variables are not put in registers
>> or "optimised away", the
On Tue, Aug 01, 2017 at 01:50:14PM +0200, David Brown wrote:
> I would not expect that to be good at all. With no optimisation (-O0),
> gcc produces quite poor code - local variables are not put in registers
> or "optimised away", there is no strength reduction, etc. For an
> architecture like th
On Tue, Aug 1, 2017 at 6:00 PM, James Greenhalgh
wrote:
> On Tue, Aug 01, 2017 at 11:12:12AM -0400, Eric Gallager wrote:
>> On 8/1/17, Jakub Jelinek wrote:
>> > On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
>> >> > Heh. I suspect -Os would benefit from a separate compilation pip
On Tue, Aug 01, 2017 at 11:12:12AM -0400, Eric Gallager wrote:
> On 8/1/17, Jakub Jelinek wrote:
> > On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
> >> > Heh. I suspect -Os would benefit from a separate compilation pipeline
> >> > such as -Og. Nowadays the early optimization pip
On 8/1/17, Jakub Jelinek wrote:
> On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
>> > Heh. I suspect -Os would benefit from a separate compilation pipeline
>> > such as -Og. Nowadays the early optimization pipeline is what you
>> > want (mostly simple CSE & jump optimizations, fo
On 31/07/17 15:25, Georg-Johann Lay wrote:
> This weekend I un-mothed an old project, just an innocent game on a
> cathode-ray-tube, driven by some AVR µC. After preparing the software
> so that it compiled with good old v3.4, the results overwhelmed me
> with complete frustration: Any version f
On 01/08/17 13:08, Eric Gallager wrote:
> On 8/1/17, Richard Biener wrote:
>>
>> Heh. I suspect -Os would benefit from a separate compilation pipeline
>> such as -Og. Nowadays the early optimization pipeline is what you
>> want (mostly simple CSE & jump optimizations, focused on code
>> size im
On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
> > Heh. I suspect -Os would benefit from a separate compilation pipeline
> > such as -Og. Nowadays the early optimization pipeline is what you
> > want (mostly simple CSE & jump optimizations, focused on code
> > size improvements).
On 8/1/17, Richard Biener wrote:
> On Mon, Jul 31, 2017 at 7:08 PM, Andrew Haley wrote:
>> On 31/07/17 17:12, Oleg Endo wrote:
>>> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
Around 2010, someone who used a code snipped that I published in
a wiki, reported that the code d
Richard Biener writes:
> On Mon, Jul 31, 2017 at 7:08 PM, Andrew Haley wrote:
> > On 31/07/17 17:12, Oleg Endo wrote:
> >> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
> >>> Around 2010, someone who used a code snipped that I published in a
> >>> wiki, reported that the code didn't
On Mon, Jul 31, 2017 at 7:08 PM, Andrew Haley wrote:
> On 31/07/17 17:12, Oleg Endo wrote:
>> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
>>> Around 2010, someone who used a code snipped that I published in
>>> a wiki, reported that the code didn't work and hang in an
>>> endless lo
On Mon, Jul 31, 2017 at 11:54:12AM -0600, Jeff Law wrote:
> On 07/31/2017 11:23 AM, Segher Boessenkool wrote:
> > On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote:
> >> I could probably write a similar rant. This is the life of a "minority
> >> target programmer". Most development effort
On 07/31/2017 11:23 AM, Segher Boessenkool wrote:
> On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote:
>> I could probably write a similar rant. This is the life of a "minority
>> target programmer". Most development efforts are being done with
>> primary targets in mind. And as a result
On 07/31/2017 10:49 AM, Joel Sherrill wrote:
>
>
> On 7/31/2017 11:12 AM, Oleg Endo wrote:
>> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
>>> Around 2010, someone who used a code snipped that I published in
>>> a wiki, reported that the code didn't work and hang in an
>>> endless l
On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote:
> I could probably write a similar rant. This is the life of a "minority
> target programmer". Most development efforts are being done with
> primary targets in mind. And as a result, most changes are being
> tested only on such targets.
On 31/07/17 17:12, Oleg Endo wrote:
> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
>> Around 2010, someone who used a code snipped that I published in
>> a wiki, reported that the code didn't work and hang in an
>> endless loop. Soon I found out that it was due to some GCC
>> problem
On Tue, 1 Aug 2017, Oleg Endo wrote:
> To improve the situation, we'd need a lot more target specific tests
> which test for those regressions that you have mentioned. Then of
> course somebody has to run all those tests on all those various
> targets. I think that's the biggest problem. But st
On 7/31/2017 11:12 AM, Oleg Endo wrote:
On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
Around 2010, someone who used a code snipped that I published in
a wiki, reported that the code didn't work and hang in an
endless loop. Soon I found out that it was due to some GCC
problem, and
On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
> Around 2010, someone who used a code snipped that I published in
> a wiki, reported that the code didn't work and hang in an
> endless loop. Soon I found out that it was due to some GCC
> problem, and I got interested in fixing the compi
Around 2010, someone who used a code snipped that I published in
a wiki, reported that the code didn't work and hang in an
endless loop. Soon I found out that it was due to some GCC
problem, and I got interested in fixing the compiler so that
it worked with my code.
1 1/2 years later, in 2011, I
36 matches
Mail list logo
