Re: Scheduler:LLVM vs gcc, which is better
Hi Chandler, Thanks a lot for your answer.It is pretty misleading to find out that DAG has schedule unit. -- Regards lin zuojian
Re: Scheduler:LLVM vs gcc, which is better
On Mon, Mar 10, 2014 at 7:33 PM, lin zuojian wrote: > Hi, > I just ask for opinions.I think many GCC developers do familiar with > the opponent.If I ask in the LLVM mailing list, I have to worry > about If they are familiar with GCC, too(what's sched2 pass?). I suspect you will have the same problem on both lists. The internal details of the scheduling system are not likely to be widely known honestly. To provide a very brief summary of what is going on in LLVM to the best of my knowledge (although I am not one of the experts on this area): The DAG (or more fully, the SelectionDAG) is not really relevant to scheduling any more[1]. It is just a mechanism used for legalization and combining the target-specific representation prior to producing very low level "MI" or Machine Instructions. That is, it is entirely an instruction selection tool, not a a scheduling tool. The scheduling takes place amongst the machine instructions either before or after register allocation (depending on the target) and with a wide variety of heuristics. My understanding is that it is attempting to solve the same fundamental scheduling problems as GCC's infrastructure (ILP and register pressure). The infrastructure is the bulk of it though, and that is likely entirely specific to the representation and innards of the respective compilers. Given that LLVM's machine level scheduler is significantly younger than GCC's, I would expect it to be less well tuned and have less complete and/or accurate modeling for some targets. -Chandler [1] Historically, we did both instruction selection and scheduling using the DAG, but the scheduling has moved into the MI layer specifically to address register pressure and ILP concerns that were hard/impossible to handle at a higher level. There is some hope that the DAG goes away completely and is replaced with some simpler selection and legalization framework, but that hasn't yet emerged.
Re: Scheduler:LLVM vs gcc, which is better
On Mon, Mar 10, 2014 at 07:11:43PM -0700, Chandler Carruth wrote: > On Mon, Mar 10, 2014 at 6:59 PM, lin zuojian wrote: > > > > Hi, > > I read LLVM code for a while,and a question raise:Whose scheduler is > > better? > > LLVM brings in the DAG,and make it look important just like IR or > > MachineInst.But is that necessary?I don't see what kind of problem > > it tries to solve. > > From the pipeline of the compiler, LLVM can not do sched2.Is that > > suck? > > I clearly can't speak for GCC developers, but as an LLVM developer I > have to say, this seems like a (somewhat rudely phrased) question for > the LLVM mailing lists where there are people more familiar with the > LLVM internals. Happy to reply in more depth there (or here if folks > are actually interested). Hi, I just ask for opinions.I think many GCC developers do familiar with the opponent.If I ask in the LLVM mailing list, I have to worry about If they are familiar with GCC, too(what's sched2 pass?). -- Regards lin zuojian
Re: Scheduler:LLVM vs gcc, which is better
On Mon, Mar 10, 2014 at 6:59 PM, lin zuojian wrote: > > Hi, > I read LLVM code for a while,and a question raise:Whose scheduler is > better? > LLVM brings in the DAG,and make it look important just like IR or > MachineInst.But is that necessary?I don't see what kind of problem > it tries to solve. > From the pipeline of the compiler, LLVM can not do sched2.Is that > suck? I clearly can't speak for GCC developers, but as an LLVM developer I have to say, this seems like a (somewhat rudely phrased) question for the LLVM mailing lists where there are people more familiar with the LLVM internals. Happy to reply in more depth there (or here if folks are actually interested).
Scheduler:LLVM vs gcc, which is better
Hi, I read LLVM code for a while,and a question raise:Whose scheduler is better? LLVM brings in the DAG,and make it look important just like IR or MachineInst.But is that necessary?I don't see what kind of problem it tries to solve. From the pipeline of the compiler, LLVM can not do sched2.Is that suck? -- Regards lin zuojian.
Re: [RL78] Questions about code-generation
> I'm curious. Have you tried out other approaches before you decided > to go with the virtual registers? Yes. Getting GCC to understand the "unusual" addressing modes the RL78 uses was too much for the register allocator to handle. Even when the addressing modes are limited to "usual" ones, GCC doesn't have a good way to do regalloc and reload when there are limits on what registers you can use in an address expression, and it's worse when there are dependencies between operands, or limited numbers of address registers.
Re: [RL78] Questions about code-generation
DJ, On Mon, 2014-03-10 at 20:17 -0400, DJ Delorie wrote: > > Ah, that certainly explains a lot. How exactly would the fixing be > > done? Is there an example I could look at for one of the other processors? > > No, RL78 is the first that uses this scheme. I'm curious. Have you tried out other approaches before you decided to go with the virtual registers? Cheers, Oleg
Re: [RL78] Questions about code-generation
> Ah, that certainly explains a lot. How exactly would the fixing be > done? Is there an example I could look at for one of the other processors? No, RL78 is the first that uses this scheme. > I calculated a week or two ago that we could make a code-saving of > around 8% by using near or relative branches and near calls instead of > always generating far calls. I changed rl78-real.md to use near > addressing and got about 5%. That's probably about right. I tried to > generate relative branches too but I'm guessing that the 'length' > attribute needs to be set for all instructions to get that working properly. Or the linker could be taught to optimize branches once it knows the full displacement, but that can be even trickier to get right.
Re: [RL78] Questions about code-generation
On 10/03/14 22:37, DJ Delorie wrote: I've managed to build GCC myself so that I could experiment a bit but as this is my first foray into compiler internals, I'm struggling to work out how things fit together and what affects what. The key thing to know about the RL78 backend, is that it has two "targets" it uses. For the first part of the compilation, up until after reload, the model uses 16 virtual registers (R8 through R15) and a virtual machine to give gcc an orthogonal model that it can generate code for. After reload, there's a "devirtualization" pass in the RL78 backend that maps the virtual model to the real model (R0 through R7), which means copying values in and out of the real registers according to which addressing modes are needed. Then GCC continues optimizing, which gets rid of most of the unneeded instructions. The problem you're probably running into is that deciding which real registers to use for each virtual one is a very tricky task, and the post-reload optimizers aren't expecing the code to look like what it does. What causes that code to be generated when using a variable instead of a fixed memory address? The use of "volatile" disables many of GCC's optimizations. I consider this a bug in GCC, but at the moment it needs to be "fixed" in the backends on a case-by-case basis. Ah, that certainly explains a lot. How exactly would the fixing be done? Is there an example I could look at for one of the other processors? It's certainly unfortunate, since an awful lot of bit-twiddling goes on with the memory-mapped hardware registers (which obviously generally need to be declared volatile). Just to get a feel for the potential gains, I've removed the volatile keyword from all the declarations and rebuilt the project. That change alone reduces the code size by 3.7%. I wouldn't want to risk running that code but the gain is certainly significant. I calculated a week or two ago that we could make a code-saving of around 8% by using near or relative branches and near calls instead of always generating far calls. I changed rl78-real.md to use near addressing and got about 5%. That's probably about right. I tried to generate relative branches too but I'm guessing that the 'length' attribute needs to be set for all instructions to get that working properly. Obviously near/far addressing would need to be controlled by an external switch to allow for processors with more than 64KB code-flash. A few small gains can be had elsewhere (using 'clrb a' in zero_extendqihi2_real, possibly optimizing addsi3_internal_real to avoid addw ax,#0 etc.). These don't save much space in our project (about 30-40 bytes perhaps) but it'll obviously vary from project to project. Regards, Richard
Re: [RL78] Questions about code-generation
> I've managed to build GCC myself so that I could experiment a bit > but as this is my first foray into compiler internals, I'm > struggling to work out how things fit together and what affects > what. The key thing to know about the RL78 backend, is that it has two "targets" it uses. For the first part of the compilation, up until after reload, the model uses 16 virtual registers (R8 through R15) and a virtual machine to give gcc an orthogonal model that it can generate code for. After reload, there's a "devirtualization" pass in the RL78 backend that maps the virtual model to the real model (R0 through R7), which means copying values in and out of the real registers according to which addressing modes are needed. Then GCC continues optimizing, which gets rid of most of the unneeded instructions. The problem you're probably running into is that deciding which real registers to use for each virtual one is a very tricky task, and the post-reload optimizers aren't expecing the code to look like what it does. > What causes that code to be generated when using a variable instead > of a fixed memory address? The use of "volatile" disables many of GCC's optimizations. I consider this a bug in GCC, but at the moment it needs to be "fixed" in the backends on a case-by-case basis.
Re: [gsoc 2014] moving fold-const patterns to gimple
On Fri, Mar 7, 2014 at 2:38 PM, Richard Biener
wrote:
> On Thu, Mar 6, 2014 at 7:17 PM, Prathamesh Kulkarni
> wrote:
>> On Thu, Mar 6, 2014 at 6:13 PM, Richard Biener
>> wrote:
>>> On Thu, Mar 6, 2014 at 1:11 PM, Prathamesh Kulkarni
>>> wrote:
On Mon, Mar 3, 2014 at 3:32 PM, Richard Biener
wrote:
> On Sun, Mar 2, 2014 at 9:13 PM, Prathamesh Kulkarni
> wrote:
>> Hi, I am an undergraduate student at University of Pune, India, and would
>> like to work on moving folding patterns from fold-const.c to gimple.
>
> I've seen the entry on our GSoC project page and edited it to discourage
> people from working on that line. See
>
> http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html
>
> for why. I think that open-coding the transforms isn't maintainable
> in the long run.
>
>> If I understand correctly, constant folding is done on GENERIC (by
>> routines in fold-const.c), and then GENERIC is lowered to GIMPLE. The
>> purpose of this project,
>> is to have constant folding to be performed on GIMPLE instead (in
>> gimple-fold.c?)
>>
>> I have a few elementary questions to ask:
>>
>> a) A contrived example:
>> Consider a C expression, a = ~0 (assume a is int)
>> In GENERIC, this would roughly be represented as:
>> modify_expr>>
>> this gets folded to:
>> modify_expr
>> and the corresponding gimple tuple generated is (-fdump-tree-gimple-raw):
>> gimple_assign
>>
>> So, instead of folding performed on GENERIC, it should be
>> done on GIMPLE.
>> So a tuple like the following should be generated by gimplification:
>>
>> and folded to (by call to fold_stmt):
>>
>> Is this the expected behavior ?
>>
>> I have attached a rough/incomplete patch (only stage1 compiled cc1), that
>> does the following foldings on bit_not_expr:
>> a) ~ INTEGER_CST => folded
>> b) ~~x => x
>> c) ~(-x) => x - 1
>> (For the moment, I put case BIT_NOT_EXPR: return NULL_TREE
>> in fold_unary_loc to avoid folding in GENERIC on bit_not_expr)
>>
>> Is the patch going in the correct direction ? Or have I completely missed
>> the point here ? I would be grateful to receive suggestions, and start
>> working
>> on a fair patch.
>
> I think you implement what was suggested by Kai (and previously
> by me and Andrew, before I changed my mind).
>
Hi Richard,
Thanks for your reply and for pointing me out to this thread
http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html
I agree it's better to generate patterns from a meta-description
instead of hand-coding, and the idea seems interesting to me.
I was playing around with the patch and did few trivial modifications
(please find the patch attached):
a) use obstack in parse_c_expr.
b) use @ inside c code, instead of directly writing captures
(like $ in bison):
example:
/* Match and simplify CST + CST to CST'. */
(define_match_and_simplify baz
(PLUS_EXPR INTEGER_CST_P@0 INTEGER_CST_P@1)
{ int_const_binop (PLUS_EXPR, @0, @1); })
c) Not sure if this is a good idea, conditional matching.
for example:
/* match (A * B) and simplify to
* B if integer_zerop B is true ( A * 0 => 0)
* A if integer_onep B is true (A * 1 => A)
*/
(define_match_and_simplify multexpr
(MULT_EXPR integral_op_p@0 integral_op_p@1)
[
(integer_zerop@1 @1)
(integer_onep@1 @0)
])
Maybe condition can be generalized to be any operand instead of
testing predicate on capture operand ?
I would be grateful to receive some direction for working on this project.
From the thread, I see a few possibilities:
a) Moving patterns from tree-ssa-forwprop
b) Extending the DSL (handle commutative operators, conditionally
enabling patterns ?)
c) Targeting GENERIC (Generating patterns in fold-const.c from the
description ?)
d) This is a bit silly, but maybe perform more error checking ?
for example the following pattern is currently accepted:
(define_match px
(PLUS_EXPR @0 @1 @2))
>>>
>>> Note that I'm currently still hacking on this (see attachment for what
>>> I have right now). The grammar is still in flux but I'd like to keep it
>>> simple for now (so no conditional replacement).
>>>
>>> I have changed quite some bits so d) should be easily possible
>>> now and I've done b) from your list as well.
>>>
>>> For the moment I'm trying to see whether the design is sound,
>>> especially the GCC-side APIs. I hope to finish this this week
>>> (fingers crossing), and also settle on the syntax (see variants in
>>> the .pd).
>>>
>>> As for opening this up for a GSOC project to "finish" or work on
>>> that's a good idea. In addition to a) Moving patterns from
>>> tree-ssa-forwprop
>>> which I think is the p
Re: GNU C extension: Function Error vs. Success
On 03/10/2014 05:26 PM, Shahbaz Youssefi wrote:
> I'm mostly interested in C. Nevertheless, you can of course also do
> the same in C:
>
> struct option_float
> {
> float value;
> int error_code;
> bool succeeded;
> };
>
> struct option_float inverse(int x) {
> if (x == 0)
> return (struct option_float){ .succeeded = false, .error_code = EDOM };
> return (struct option_float){ .value = 1.0f / x, .succeeded = true };
> }
>
Well, yes. This is rather wordy, but indeed it does the same thing.
> P.S. programming in a lot of languages is _mere syntax_ with respect
> to some others. Still, some syntaxes are good and some not. If we can
> improve GNU C's syntax to be shorter, but without loss of
> expressiveness or clarity, then why not!
Because C is a simple language. That's a feature: if you want more
language complexity, and C++ can already do what you want, what not
use C++? The usual argument is "I don't want all this other stuff."
Well, don't use it, then!
There seem to be many people who what what C++ can do, but say "I don't
want to use C++."
Andrew.
Re: GNU C extension: Function Error vs. Success
I'm mostly interested in C. Nevertheless, you can of course also do
the same in C:
struct option_float
{
float value;
int error_code;
bool succeeded;
};
struct option_float inverse(int x) {
if (x == 0)
return (struct option_float){ .succeeded = false, .error_code = EDOM };
return (struct option_float){ .value = 1.0f / x, .succeeded = true };
}
you get the idea. The difference is that it's hard to optimize the
non-error execution path if the compiler is not aware of the
semantics. Also, with exceptions, this can happen:
float inverse(int x)
{
if (x == 0)
throw overflow;
return 1.0f / x;
}
y = inverse(x);
Which means control is taken from the function calling inverse without
it explicitly allowing it, which is not in the spirit of C.
P.S. programming in a lot of languages is _mere syntax_ with respect
to some others. Still, some syntaxes are good and some not. If we can
improve GNU C's syntax to be shorter, but without loss of
expressiveness or clarity, then why not!
On Mon, Mar 10, 2014 at 6:18 PM, Andrew Haley wrote:
> On 03/10/2014 03:09 PM, Shahbaz Youssefi wrote:
>> Regarding C++ exceptions: exceptions are not really nice. They can
>> just make your function return without you even knowing it (forgetting
>> a `try/catch` or not knowing it may be needed, which is C++'s fault
>> and probably could have been done better). Also, they require
>> complicated operations. You can read a small complaint about it here:
>> http://stackoverflow.com/a/1746368/912144 and I'm sure there are many
>> others on the internet.
>
> A few quibbles here.
>
> Firstly, C++ exceptions do not require complicated operations: an
> implementation may well do complicated things, but that's not the
> same at all. In GCC we use DWARF exception handling, which is
> designed to be near-zero-cost for exceptions that are not thrown,
> but is more expensive when they are.
>
> There is no inherent reason why
>
> float inverse(int x)
> {
> if (x == 0)
> fail;
> return 1.0f / x;
> }
>
> y = inverse(x) !! goto exit_inverse_failed;
>
> should not generate the same code as
>
> float inverse(int x)
> {
> if (x == 0)
> throw overflow;
> return 1.0f / x;
> }
>
> try {
> y = inverse(x);
> } catch (IntegerOverflow e) {
> goto exit_inverse_failed;
> }
>
> This assumes, of course, a knowledgeable optimizing compiler.
>
> Also, consider that C++ can already do almost what you want.
> Here we have a function that returns a float wrapped with a
> status:
>
> option inverse(float x) {
> if (x == 0)
> return option(); // No value...
> return 1.0f / x;
> }
>
> float poo(float x) {
> option res = inverse(x);
> if (res.none())
> return 0;
> return res;
> }
>
> GCC generates, quite nicely:
>
> poo(float):
> xorps %xmm1, %xmm1
> ucomiss %xmm1, %xmm0
> jp .L12
> jne .L12
> movaps %xmm1, %xmm0
> ret
> .L12:
> movss .LC1(%rip), %xmm1
> divss %xmm0, %xmm1
> movaps %xmm1, %xmm0
> ret
>
> The difference between
>
> y = inverse(x) !! goto exit_inverse_failed;
>
> and
>
> option y = inverse(x);
> if (y.none())
> goto exit_inverse_failed;
>
> is, I suggest to you, mere syntax. The latter is more explicit.
>
> Andrew.
>
Re: GNU C extension: Function Error vs. Success
On 03/10/2014 03:09 PM, Shahbaz Youssefi wrote:
> Regarding C++ exceptions: exceptions are not really nice. They can
> just make your function return without you even knowing it (forgetting
> a `try/catch` or not knowing it may be needed, which is C++'s fault
> and probably could have been done better). Also, they require
> complicated operations. You can read a small complaint about it here:
> http://stackoverflow.com/a/1746368/912144 and I'm sure there are many
> others on the internet.
A few quibbles here.
Firstly, C++ exceptions do not require complicated operations: an
implementation may well do complicated things, but that's not the
same at all. In GCC we use DWARF exception handling, which is
designed to be near-zero-cost for exceptions that are not thrown,
but is more expensive when they are.
There is no inherent reason why
float inverse(int x)
{
if (x == 0)
fail;
return 1.0f / x;
}
y = inverse(x) !! goto exit_inverse_failed;
should not generate the same code as
float inverse(int x)
{
if (x == 0)
throw overflow;
return 1.0f / x;
}
try {
y = inverse(x);
} catch (IntegerOverflow e) {
goto exit_inverse_failed;
}
This assumes, of course, a knowledgeable optimizing compiler.
Also, consider that C++ can already do almost what you want.
Here we have a function that returns a float wrapped with a
status:
option inverse(float x) {
if (x == 0)
return option(); // No value...
return 1.0f / x;
}
float poo(float x) {
option res = inverse(x);
if (res.none())
return 0;
return res;
}
GCC generates, quite nicely:
poo(float):
xorps %xmm1, %xmm1
ucomiss %xmm1, %xmm0
jp .L12
jne .L12
movaps %xmm1, %xmm0
ret
.L12:
movss .LC1(%rip), %xmm1
divss %xmm0, %xmm1
movaps %xmm1, %xmm0
ret
The difference between
y = inverse(x) !! goto exit_inverse_failed;
and
option y = inverse(x);
if (y.none())
goto exit_inverse_failed;
is, I suggest to you, mere syntax. The latter is more explicit.
Andrew.
Re: GNU C extension: Function Error vs. Success
Thanks for the hint. I would try to learn how to do that and
experiment on the idea if/when I get the time. I could imagine why the
community isn't interested in new syntax in general. Still, you may
never know if an idea would be attractive enough to generate some
attention! :)
On Mon, Mar 10, 2014 at 4:26 PM, Basile Starynkevitch
wrote:
> On Mon, Mar 10, 2014 at 03:27:06PM +0100, Shahbaz Youssefi wrote:
>> Hi,
>>
>> First, let me say that I'm not subscribed to the mailing list, so
>> please CC myself when responding.
>>
>> This post is to discuss a possible extension to the GNU C language.
>> Note that this is still an idea and not refined.
> []
>>
>> The Extension (Basic)
>> =
>>
>> First, let's introduce a new syntax (note again, this is just an
>> example. I don't suggest these particular symbols):
>>
>> float inverse(int x)
>> {
>> if (x == 0)
>> fail;
>> return 1.0f / x;
>> }
>>
>> ...
>> y = inverse(x) !! goto exit_inverse_failed;
>>
>
>
> Syntax is not that important. To experiment your idea,
> I would suggest using a mixture of pragmas and builtins;
> you could perhaps have a new builtin_shahbaz_fail() and a pragma
> #pragma SHAHBAZ and then your temporary syntax would be
>
> float inverse(int x)
> {
> if (x == 0) builtin_shahbaz_fail();
> return 1.0f / x;
> }
>
> #pragma SHAHBAZ on_error_goto(exit_inverse_failed)
> { y = inverse(x); }
>
>
> Then, you don't need to dig into GCC parser to add these builtin and pragma.
> You could add them with a GCC plugin (in C++) or using MELT
> http://gcc-melt.org/
>
> Once you added a GCC pass to support your builtin and pragma
> (which is difficult, and means understanding the details of internals of GCC)
> you could convince other people.
>
> Notice that the GCC community is not friendly these days to new syntactic
> constructs.
>
> BTW, once you have implemented a builtin and a pragma you could use
> preprocessor macros
> to make these look more like your syntax.
>
>
> I would believe that MELT is very well suited for such experiments.
>
> Regards.
>
> PS. Plugins cannot extend the C syntax (except thru attributes, builtins,
> pragmas).
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
Re: GNU C extension: Function Error vs. Success
10.03.2014 18:27, Shahbaz Youssefi пишет:
FILE *fin = fopen("filename", "r") !! goto exit_no_file;
Or maybe permission denied? ;-)
[RL78] Questions about code-generation
Hi,
The code produced by GCC for the RL78 target is around twice as large as that
produced by IAR and I've been trying to find out why.
The project I'm working on uses an RL78/F12 with 16KB of code flash. As I have
to get a bootloader and an application into that, I have to pay close attention
to how large the code is becoming.
Looking at the assembler output for some simple examples, the problem seems to
be 'bloated' code as opposed to not squeezing every last byte out through the
use of ingenious optimization tricks.
I've managed to build GCC myself so that I could experiment a bit but as this
is my first foray into compiler internals, I'm struggling to work out how
things fit together and what affects what.
My initial impression is that significant gains could be made by clearing away
some low-hanging fruit, but without understanding what caused that code to be
generated in the first place, it's hard to do anything about it.
In particular, I'd be interested to know what is caused (or could be improved)
by the RL78-specific code, and what comes from the generic part of GCC.
Here's an example extracted from one of the functions in our project:
unsigned short gOrTest;
#define SOE0 (*(volatile unsigned short *)0xF012A)
void orTest()
{
SOE0 |= 3;
/* gOrTest |= 3; */
}
This produces the following code (using -Os):
29 C9 F2 2A 01 movw r10, #298
30 0004 AD F2 movw ax, r10
31 0006 16 movw hl, ax
32 0007 AB movw ax, [hl]
33 0008 BD F4 movw r12, ax
34 000a 60 mov a, x
35 000b 6C 03 or a, #3
36 000d 9D F0 mov r8, a
37 000f 8D F5 mov a, r13
38 0011 9D F1 mov r9, a
39 0013 AD F2 movw ax, r10
40 0015 12 movw bc, ax
41 0016 AD F0 movw ax, r8
42 0018 78 00 00 movw [bc], ax
43 001b D7 ret
There's so much unnecessary register passing going on there (#298 could go
straight into HL, why does the same value end up in BC even though HL hasn't
been touched? etc.)
Commenting out the 'SOE0' line and bringing the 'gOrTest' line back in
generates better code (but still worthy of optimization):
29 8F 00 00 mov a, !_gOrTest
30 0003 6C 03 or a, #3
31 0005 9F 00 00 mov !_gOrTest, a
32 0008 8F 00 00 mov a, !_gOrTest+1
33 000b 6C 00 or a, #0
34 000d 9F 00 00 mov !_gOrTest+1, a
35 0010 D7 ret
What causes that code to be generated when using a variable instead of a fixed
memory address?
Even allowing for the unnecessary 'or a, #0' and keeping to a 16-bit access,
it's still possible to perform the same operation in half the space of the
original:
29 36 2A 01 movw hl, #298
30 0003 AB movw ax, [hl]
31 0004 75 mov d, a
32 0005 60 mov a, x
33 0006 6C 03 or a, #3
34 0008 70 mov x, a
35 0009 65 mov a, d
36 000a 6C 00 or a, #0
37 000c BB movw [hl], ax
38 000d D7 ret
And, of course, that could be optimized further.
Excessive register copying and an apparant preference for R8 onwards over the
B,C,D,E,H and L registers (which could save a byte on every 'mov') seems to be
one of the main causes of 'bloated' code (among others).
So, I guess my question is how much of the bloat comes from inefficiencies in
the hardware-specific code? I saw a comment in the RL78 code about performing
CSE optimization but it's not clear to me where or how that would be done. I
tried to look at the code for some other processors to get an idea but it's
hard to find things when you don't
know what you're looking for :)
Any help would be gratefully received!
Regards,
Richard Hulme
Re: GNU C extension: Function Error vs. Success
On Mon, Mar 10, 2014 at 03:27:06PM +0100, Shahbaz Youssefi wrote:
> Hi,
>
> First, let me say that I'm not subscribed to the mailing list, so
> please CC myself when responding.
>
> This post is to discuss a possible extension to the GNU C language.
> Note that this is still an idea and not refined.
[]
>
> The Extension (Basic)
> =
>
> First, let's introduce a new syntax (note again, this is just an
> example. I don't suggest these particular symbols):
>
> float inverse(int x)
> {
> if (x == 0)
> fail;
> return 1.0f / x;
> }
>
> ...
> y = inverse(x) !! goto exit_inverse_failed;
>
Syntax is not that important. To experiment your idea,
I would suggest using a mixture of pragmas and builtins;
you could perhaps have a new builtin_shahbaz_fail() and a pragma
#pragma SHAHBAZ and then your temporary syntax would be
float inverse(int x)
{
if (x == 0) builtin_shahbaz_fail();
return 1.0f / x;
}
#pragma SHAHBAZ on_error_goto(exit_inverse_failed)
{ y = inverse(x); }
Then, you don't need to dig into GCC parser to add these builtin and pragma.
You could add them with a GCC plugin (in C++) or using MELT http://gcc-melt.org/
Once you added a GCC pass to support your builtin and pragma
(which is difficult, and means understanding the details of internals of GCC)
you could convince other people.
Notice that the GCC community is not friendly these days to new syntactic
constructs.
BTW, once you have implemented a builtin and a pragma you could use
preprocessor macros
to make these look more like your syntax.
I would believe that MELT is very well suited for such experiments.
Regards.
PS. Plugins cannot extend the C syntax (except thru attributes, builtins,
pragmas).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: GNU C extension: Function Error vs. Success
Hi Julian, Thanks for the feedback. Regarding C++ exceptions: exceptions are not really nice. They can just make your function return without you even knowing it (forgetting a `try/catch` or not knowing it may be needed, which is C++'s fault and probably could have been done better). Also, they require complicated operations. You can read a small complaint about it here: http://stackoverflow.com/a/1746368/912144 and I'm sure there are many others on the internet. Regarding OCaml option types: in fact I did think of this separation after learning about monads (through Haskell though). However, personally I don't see how monads could be introduced in C without majorly affecting syntax and ABI. Regarding the syntax: You are absolutely right. I don't claim that this particular syntax is ideal. I'm sure the many minds in this mailing list are able to find a more beautiful syntax, if they are interested in the idea. Nevertheless, the following code: x = foo() + bar(); doesn't do any error checking. I.e. it assumes `foo` and `bar` are unfailable. If that is the case, there is no need for a `!! goto fail_label` at all. I personally have never seen such an expression followed by e.g. if (x ) goto foo_or_bar_failed; On the other hand, something like this is common: while (func(...) == 0) which, if turned to e.g.: while (func(...) !! break) or fail_code=0; while (func(...) !!= fail_code, fail_code == 0) could seem awkward at best. My hope is that through this discussion, we would be able to figure out a way to separate success and failure of functions with minimal change to the language. My syntax is based on having the return value intact while returning the success-failure and error-code in registers both for speed and compatibility and let the compiler generate the repetitive/ugly error-checking code. Other than that, I personally don't have any attachments to the particular way it's embedded in the grammar of GNU C. On Mon, Mar 10, 2014 at 3:50 PM, Julian Brown wrote: > On Mon, 10 Mar 2014 15:27:06 +0100 > Shahbaz Youssefi wrote: > >> Feedback >> >> >> Please let me know what you think. In particular, what would be the >> limitations of such a syntax? Would you be interested in seeing this >> extension to the GNU C language? What alternative symbols do you think >> would better show the intention/simplify parsing/look more beautiful? > > I suggest you think about how this is better than C++ exceptions, and > also consider alternatives like OCaml's option types that can be used > to achieve similar ends. > > For your suggested syntax at function call sites, consider that > functions can be called in more complicated ways than simply as "bar = > foo();" statements, and the part following the "!!" in your examples > appears to be a statement itself: in more complicated expressions, that > interleaving of expressions and statements going to get very ugly very > quickly. E.g.: > > x = foo() + bar(); > > would need to become something like: > > x = (foo() !! goto label1) + (bar () !! goto label2); > > And there are all sorts of issues with that. > > Anyway, I quite like the idea of rationalising error-code returns in C > code, but I don't think this is the right way of going about it. > > HTH, > > Julian
Re: GNU C extension: Function Error vs. Success
On Mon, 10 Mar 2014 15:27:06 +0100 Shahbaz Youssefi wrote: > Feedback > > > Please let me know what you think. In particular, what would be the > limitations of such a syntax? Would you be interested in seeing this > extension to the GNU C language? What alternative symbols do you think > would better show the intention/simplify parsing/look more beautiful? I suggest you think about how this is better than C++ exceptions, and also consider alternatives like OCaml's option types that can be used to achieve similar ends. For your suggested syntax at function call sites, consider that functions can be called in more complicated ways than simply as "bar = foo();" statements, and the part following the "!!" in your examples appears to be a statement itself: in more complicated expressions, that interleaving of expressions and statements going to get very ugly very quickly. E.g.: x = foo() + bar(); would need to become something like: x = (foo() !! goto label1) + (bar () !! goto label2); And there are all sorts of issues with that. Anyway, I quite like the idea of rationalising error-code returns in C code, but I don't think this is the right way of going about it. HTH, Julian
GNU C extension: Function Error vs. Success
Hi,
First, let me say that I'm not subscribed to the mailing list, so
please CC myself when responding.
This post is to discuss a possible extension to the GNU C language.
Note that this is still an idea and not refined.
Background
==
In C, the following code structure is ubiquitous:
return value = function_call(arguments);
if (return_value == ERROR_VALUE)
goto exit_fail;
You can take a look at goto usages in the Linux kernel just for
examples (https://github.com/torvalds/linux/search?q=goto).
However, this method has one particular drawback, besides verbosity
among others. This drawback is that each function has to designate (at
least) one special value as ERROR_VALUE. Trivial as it may seem, this
has by itself resulted in many inconsistencies and problems. For
example, `malloc` signals failure by returning `NULL`, `strtod` may
return 0, `HUGE_VAL*` etc, `fread` returns 0 which is not necessarily
an error case either, `fgetc` returns `EOF`, `remove` returns nonzero
if failed, `clock` returns -1 and so on.
Sometimes such a special value may not even be possible, in which case
a workaround is required (put the return value as a pointer argument
and return the state of success).
The following suggestion allows clearer and shorter error handling.
The Extension (Basic)
=
First, let's introduce a new syntax (note again, this is just an
example. I don't suggest these particular symbols):
float inverse(int x)
{
if (x == 0)
fail;
return 1.0f / x;
}
...
y = inverse(x) !! goto exit_inverse_failed;
The semantics of this syntax would be as follows. The function
`inverse` can choose to `fail` instead of `return`, in which case it
doesn't actually return anything. From the caller site, this failure
is signaled (speculations on details below), `y` is not assigned and a
`goto exit_inverse_failed` is executed. The observed behavior would be
equivalent to:
int inverse(int x, float *y)
{
if (x == 0)
return -1;
*y = 1.0f / x;
return 0;
}
...
if (inverse(x, &y))
goto exit_inverse_failed;
The Extension (Advanced)
Sometimes, error handling is done not just by a single `goto`
(although they can all be reduced to this). For example:
return value = function_call(arguments);
if (return_value == ERROR_VALUE)
{
/* a small piece of code, such as printing an error */
goto exit_fail;
}
This could be shortened as:
return value = function_call(arguments) !! {
/* a small piece of code, such as printing an error */
goto exit_fail;
}
A generic syntax could therefore be used:
return value = function_call(arguments) !! goto exit_fail;
return value = function_call(arguments) !! fail;
return value = function_call(arguments) !! return 0;
return value = function_call(arguments) !! {
/* more than one statement */
}
Another necessity is for the error code. While `errno` is usable, it's
not the best solution in the world. Extending the syntax further, the
following could be used (again, syntax is just for the sake of
example, I'm not suggesting these particular symbols):
float inverse(int x)
{
if (x == 0)
fail EDOM;
return 1.0f / x;
}
...
y = inverse(x) !!= error_code !! goto exit_inverse_failed;
By this, the function `inverse` can `fail` with an error code (again,
speculations of details below), which can be stored in a variable
(`error_code`) in call site.
Some Details
==
The state of failure and success as well as the failure code can be
kept in registers, to keep the ABI backward-compatible.
If backward compatibility is required, a `fail`able function must
still provide a fail value (simply to keep older code intact), which
could have a syntax as follows (for example):
float inverse(int x) !! 0
{
if (x == 0)
fail EDOM;
return 1.0f / x;
}
...
y = inverse(x);
In this example, the caller doesn't check for failure and would
receive the fail value indicated by the function signature. If no such
fail value is given, the caller must check for failure. This allows
older code, such as the standard library to be possibly used in the
way it has always been (by providing fail value) or with this
extension, while allowing cleaner and more robust code to be written
(by not providing fail value).
Examples
Here are some examples.
Opening a file and reading a number (normal C):
int n;
FILE *fin = fopen("filename", "r");
if (fin == NULL)
goto exit_no_file;
if (fscanf(fin, "%d", &n) != 1)
if (ferror(fin))
goto exit_io_error;
else
{ /* complain about format */ }
fclose(fin);
return 0;
exit_io_error:
/* print error: I/O error */
status of current_pass (notably in gates) .... [possible bug in 4.9]
Hello All,
I am a bit confused (or unhappy) about the current_pass variable
(in GCC 4.9 svn rev.208447); I believe we have some incoherency about it.
It is generally (as it used to be in previous versions of GCC)
a global pointer to some opt_pass, declared in gcc/tree-pass.h line 590.
It is also (and independently), a local integer in function
connect_traces file gcc/bb-reorder.c line 1042. I feel that
for readability reasons the local current_pass should be renamed
current_pass_num in the function connect_traces.
But most importantly, I find confusing the way current_pass pointer is
globally set (and reset). The obvious policy seems to set current_pass to
"this" before calling any virtual methods on it (notably the gate and
the exec functions).
However, if one use -fdump-passes program argument to gcc (i.e. to cc1), then
dump_passes (from gcc/passes.c line 892) gets called. It then calls function
dump_one_pass (from gcc/passes.c line 851) which does line 857
is_on = pass->has_gate ? pass->gate () : true;
But in other occasions, notably in function execute_one_pass
(starting at gcc/passes.c line 2153) the global current_pass is
set (line 2166) before calling its gate function line 2170
gate_status = pass->has_gate ? pass->gate () : true;
I believe something should be done about this, since it seems to confuse
plugins (like MELT). Either we decide that current_pass is always set
before calling any virtual function on it (notably the gate) or we
decide that current_pass global should disappear (but then, what
about the curr_statistics_hash function from gcc/statistics.c line 93
which uses it line 98)?
Comments are welcome. I think we should do something about this before
releasing GCC 4.9...
The simplest thing would be to set current_pass in dump_one_pass
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [AVR] remove two maintainers
On 10/03/14 11:29, Jeremy Bennett wrote: > On 03/03/14 11:35, David Brown wrote: >> On 02/03/14 19:24, Denis Chertykov wrote: >>> I would remove two maintainers for AVR port: >>> 1. Anatoly Sokolov >>> 2. Eric Weddington >>> >>> I have discussed the removal with Anatoly Sokolov and he is agree with it. >>> I can't discuss the removal with Eric Weddington because his mail >>> address invalid. >>> >>> Must somebody approve the removal ? (Or I can just apply it) >>> >>> Denis. >>> >> >> Eric Weddington has left Atmel, so his address will no longer be valid. >> I don't know if he still has time to work with AVRs, or if he would >> still be able to be a maintainer for the AVR port. But I am pretty sure >> that his new job will not involve AVR's significantly, so it would only >> be as a hobby (or at best, as a normal avr gcc user). >> >> Atmel includes gcc in their development tool (AVR Studio), as well as >> providing pre-built packages (for Windows and Linux) with the avr-libc >> library and related tools, using snapshots of mainline gcc with a few >> patches (for things like support of newer devices). So it seems >> reasonable to expect that they will be interested in the development and >> maintenance of the avr port of gcc even though Eric has now left them. >> If you would like, I can try to contact Atmel and ask if they have >> someone who would like to take Eric's seat as a port maintainer (or you >> could do so yourself from Atmel's website). > > Hi David, > > Joern Rennecke is working with Atmel on the AVR tool chain. You'll see > he has submitted quite a large number of AVR related patches in the last > year. > > I've discussed with Atmel's teams in Trondheim and Chennai and they are > very supportive of Joern Rennecke being added as a maintainer. > > Best wishes, > > > Jeremy > Hi, It is up to Denis and Joern (or Jørn, as I expect he spells it) to agree on maintainer status - I was just trying to provide a little helpful information. I haven't seen Jørn posting to the avr-gcc-l...@nongnu.org, where many avr-gcc users and developers hang out, but I am very happy to see that Atmel is supporting him in his work on gcc. mvh., David
dom requires PROP_loops
Hello, In an attempt to test some optimization I destroyed the loop property in pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I noticed that pass_dominator started generating wrong code. My guess is that we should mark pass_dominator with PROP_loops as a required property? Do you agree? Cheers, Paulo Matos
Re: linux says it is a bug
On Wed, Mar 05, 2014 at 10:39:51AM +0400, Yury Gribov wrote: > >What is volatile instructions? Can you give us an example? > > Check volatile_insn_p. AFAIK there are two classes of volatile instructions: > * volatile asm > * unspec volatiles (target-specific instructions for e.g. protecting > function prologues) > > -Y Thanks.
Re: [AVR] remove two maintainers
On 03/03/14 11:35, David Brown wrote: > On 02/03/14 19:24, Denis Chertykov wrote: >> I would remove two maintainers for AVR port: >> 1. Anatoly Sokolov >> 2. Eric Weddington >> >> I have discussed the removal with Anatoly Sokolov and he is agree with it. >> I can't discuss the removal with Eric Weddington because his mail >> address invalid. >> >> Must somebody approve the removal ? (Or I can just apply it) >> >> Denis. >> > > Eric Weddington has left Atmel, so his address will no longer be valid. > I don't know if he still has time to work with AVRs, or if he would > still be able to be a maintainer for the AVR port. But I am pretty sure > that his new job will not involve AVR's significantly, so it would only > be as a hobby (or at best, as a normal avr gcc user). > > Atmel includes gcc in their development tool (AVR Studio), as well as > providing pre-built packages (for Windows and Linux) with the avr-libc > library and related tools, using snapshots of mainline gcc with a few > patches (for things like support of newer devices). So it seems > reasonable to expect that they will be interested in the development and > maintenance of the avr port of gcc even though Eric has now left them. > If you would like, I can try to contact Atmel and ask if they have > someone who would like to take Eric's seat as a port maintainer (or you > could do so yourself from Atmel's website). Hi David, Joern Rennecke is working with Atmel on the AVR tool chain. You'll see he has submitted quite a large number of AVR related patches in the last year. I've discussed with Atmel's teams in Trondheim and Chennai and they are very supportive of Joern Rennecke being added as a maintainer. Best wishes, Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Twitter: @jeremypbennett Email: jeremy.benn...@embecosm.com Web: www.embecosm.com
