RE: A case exposing code sink issue
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, December 27, 2011 5:10 PM
> To: 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> >
> > The job to do this is final value replacement, not sinking (we do not
> > sink non-invariant expressions - you'd have to translate them through
> > the loop-closed SSA exit PHI node, certainly doable, patches
> > welcome ;)).
> >
>
> Richard,
>
> In final value replacement, expression "&a + D." can be figured out,
> while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we should
> lower
> &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It seems GCC intends to
> keep
> &a[i_xxx] until cfgexpand pass. Or we have to directly modify CHREC
> algorithm to get it calculated?
>
> Appreciate your kindly help in advance!
>
Richard,
Now I have a patch working for the case of step "i++", by directly modifying
scalar evolution algorithm. the following code would be generated after
SCCP,
l
# i_13 = PHI
a_p.0_4 = &a[i_13];
MEM[(int *)&a][i_13] = 100;
i_6 = i_13 + 1;
if (i_6 <= 999)
goto ;
else
goto ;
:
a_p_lsm.5_11 = &MEM[(void *)&a + 3996B];
a_p = a_p_lsm.5_11;
goto ;
It looks good, but I still have problem when the case has step "i+=k".
For this case the value of variable i exiting loop isn't invariant, the
algorithm below in scalar evolution doesn't work on it,
compute_overall_effect_of_inner_loop()
{
...
tree nb_iter = number_of_latch_executions (inner_loop);
if (nb_iter == chrec_dont_know)
return chrec_dont_know;
else
{
tree res;
/* evolution_fn is the evolution function in LOOP. Get
its value in the nb_iter-th iteration. */
res = chrec_apply (inner_loop->num, evolution_fn, nb_iter);
if (chrec_contains_symbols_defined_in_loop (res, loop->num))
res = instantiate_parameters (loop, res);
/* Continue the computation until ending on a parent of LOOP.
*/
return compute_overall_effect_of_inner_loop (loop, res);
}
}
In theory, we can still have the transformation like below even if the step
is "i+=k",
# i_13 = PHI
i_14 = i_13,
a_p.0_4 = &a[i_13];
MEM[(int *)&a][i_13] = 100;
i_6 = i_13 + k_2(D); // i+=k
if (i_6 <= 999)
goto ;
else
goto ;
:
a_p_lsm.5_11 = &a[i_14];
a_p = a_p_lsm.5_11;
goto ;
But I realize this is not a loop closed SSA form at all, because i_14 is
being used out of the loop. Where could we extend the liverange of variable
i in GCC infrastructure and finally solve this problem?
> Thanks,
> -Jiangning
>
>
>
Re: FW: a nifty feature for c preprocessor
On 28/12/2011 07:48, R A wrote: i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an "evaluation" feature. I think you have missed the point about the C pre-processor. It is not a "metaprogramming" language - it is a simple text substitution macro processor. It does not have any understanding of the symbols (except for "#") in the code, nor does it support recursion - it's pure text substitution. Your suggestion would therefore need a complete re-design of the C pre-processor. And the result is not a feature that people would want. Many uses of the C pre-processor are deprecated with modern use of C and C++. Where possible, it is usually better programming practice to use a "static const" instead of a simple numeric "#define", and a "static inline" function instead of a function-like macro. With C++, even more pre-processor functionality can be replaced by language features - templates give you metaprogramming. There are plenty of exceptions, of course, but in general it is better to use a feature that is part of the language itself (C or C++) rather than the preprocessor. It looks like you are wanting to get the compiler to pre-calculate results rather than have them calculated at run-time. That's a good idea - so the gcc developers have worked hard to make the compiler do that in many cases. If your various expressions here boil down to constants that the compiler can see, and you have at least some optimisation enabled, then it will pre-calculate the results. If you have particular need of more complicated pre-processing, then what you want is generally some sort of code generator. C has a simple enough syntax - write code in any language you want (C itself, or anything else) that outputs a C file. I've done that a few times, such as for scripts to generate CRC tables. And if you really want to use a pre-processing macro style, then there are more powerful languages suited to that. You could use PHP, for example - while the output of a PHP script is usually HTML, there is no reason why it couldn't be used as a C pre-processor. say i have these definitions: #define MACRO_1 (x/y)*y #define MACRO_2 sqrt(a) #define MACRO_3 calc13() #define MACRO_15 (a + b)/c now, all throughout the codebase, whenever and whichever of MACRO_1, or MACRO_2 (or so forth) needs to be called, they are conveniently "indexed" by another macro expansion: #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) CONCAT(a, b) #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, N) now, if we use MASTER_MACRO with a "direct" value: MASTER_MACRO(10) or #define N 10 MASTER_MACRO(10) both will work. but substitute this with: #define N((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) and MASTER_MACRO expands to: MACRO_((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) which, of course is wrong. there are other workarounds or many times this scheme can be avoided altogether. but it can be made to work (elegantly) by adding an "eval" preprocessor operation: so we redefine MASTER_MACRO this way: #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, eval(N)) which evaluates correctly. this nifty trick (though a bit extended than what i elaborated above) can also be used to *finally* have increments and decrements (among others). since "eval" forces the evaluation of an *arithmetic* expression (for now), it will force the evaluation of an expression, then define it to itself. this will of course trigger a redefinition flag from our beloved preprocessor, but the defined effect would be: #define X (((14*x)/y)/z)/* say this evaluates to simply 3 */ incrementing X, will simply be: #define X eval(eval(X) + 1)/* 1) will be evaluated as 4 before any token substitution */ #define X eval(eval(X) + 1)/* 2) will be evaluated as 5 before any token substitution */ that easy. to suppress the redef warnings, we can have another directive like force_redef (which can only work in conjunction with eval) #force_redef X eval(eval(X) + 1) i'm just confused :-S... why hasn't this been suggested? i would love to have this incorporated (even just on test builds) to gcc. it would make my code so, so much more manageable and virtually extensible to more platforms. i would love to have a go at it and probably modify the gcc preprocessor, but i since i know nothing of it's implementation details, i don't know where to begin. i was hoping that this being a gnu implementation, it's been heavily modularized (the fact that gcc was heavily revised back then to use abstract syntax trees, gimple, etc, past version 2.95 -- ???). so i can easi
return vs simple_return
Hi -- I've run into a problem with the MicroBlaze backend where it is not recognizing a return pattern. I'm trying to modify the back end to use the 'simple_return' pattern, rather than 'return', since MicroBlaze has exactly what the documentation describes: a no-frills return instruction which does nothing more than branch back to the caller. When I define only 'simple_return', there are undefined references in function.c for emit_return_into_block() and emit_use_return_register_into_block(), since these are defined when HAVE_return is defined. MIPS has a similar call/return model, with a trivial return instruction. mips.md defines expanders for both 'return' and 'simple_return' and identical insn's for both which generate the return jump. ARM also has a simple return, but the back end defines 'return' and does not define 'simple_return'. My guess is that the #ifdef HAVE_return in function.c which surrounds the undefined functions should be removed. What is the correct model for the back end? Define only 'return' like ARM, define both 'return' and 'simple_return' like MIPS, or define only 'simple_return' like I tried to do? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
RE: a nifty feature for c preprocessor
yes, i do realize that c preprocessor is but a text substitution tool from days past when programmers where only starting to develop the rudimentaries of high-level programming. but the reason i'm sticking with the c preprocessor if the fact that code that i write from it is extremely portable. copy the code and you can use it in any IDE or stand-alone compiler, it's as simple as that. i have considered using gnu make, writing scripts with m4 and other parsers or lexers, but sticking with the preprocessor's minimalism is still too attractive an idea. about the built in features in c and C++ to alleviate the extensive use for the preprocessor, like inline functions, static consts. the fact is NOT ALL compilers out there would optimize a function so that it will not have to use a return stack. simply using a macro FORCES the compiler to do so. the same goes for static const, if you use a precompiled value, you are forcing an immediate addressing, something of a good optimization. so it's still mostly an issue of portability of optimization. templates, i have no problem with, i wish there could be a C dialect that can integrate it, so i wouldn't have to be forced to use C++ and all the bloat that usually come from a lot of it's implementation (by that i mean a performance close to C i think is very possible for C++'s library). but, of course, one has to ask "if you're making your code portable to any C compiler, why do you want gcc to change (or modify it for your own use)? you should be persuading the c committee." well, that's the thing, it's harder to do the latter, so by doing this, i can demonstrate that it's a SIMPLE, but good idea. > Date: Wed, 28 Dec 2011 10:57:28 +0100 > From: da...@westcontrol.com > To: ren_zokuke...@hotmail.com > CC: gcc@gcc.gnu.org > Subject: Re: FW: a nifty feature for c preprocessor > > On 28/12/2011 07:48, R A wrote: > > > > i'm an amateur programmer that just started learning C. i like most > > of the features, specially the c preprocessor that it comes packed > > with. it's an extremely portable way of implementing metaprogramming > > in C. > > > > though i've always thought it lacked a single feature -- an > > "evaluation" feature. > > > > > I think you have missed the point about the C pre-processor. It is not > a "metaprogramming" language - it is a simple text substitution macro > processor. It does not have any understanding of the symbols (except > for "#") in the code, nor does it support recursion - it's pure text > substitution. Your suggestion would therefore need a complete re-design > of the C pre-processor. And the result is not a feature that people > would want. > > Many uses of the C pre-processor are deprecated with modern use of C and > C++. Where possible, it is usually better programming practice to use a > "static const" instead of a simple numeric "#define", and a "static > inline" function instead of a function-like macro. With C++, even more > pre-processor functionality can be replaced by language features - > templates give you metaprogramming. There are plenty of exceptions, of > course, but in general it is better to use a feature that is part of the > language itself (C or C++) rather than the preprocessor. > > It looks like you are wanting to get the compiler to pre-calculate > results rather than have them calculated at run-time. That's a good > idea - so the gcc developers have worked hard to make the compiler do > that in many cases. If your various expressions here boil down to > constants that the compiler can see, and you have at least some > optimisation enabled, then it will pre-calculate the results. > > > If you have particular need of more complicated pre-processing, then > what you want is generally some sort of code generator. C has a simple > enough syntax - write code in any language you want (C itself, or > anything else) that outputs a C file. I've done that a few times, such > as for scripts to generate CRC tables. > > And if you really want to use a pre-processing macro style, then there > are more powerful languages suited to that. You could use PHP, for > example - while the output of a PHP script is usually HTML, there is no > reason why it couldn't be used as a C pre-processor. > > > > > > say i have these definitions: #define MACRO_1 (x/y)*y > > #define MACRO_2 sqrt(a) #define MACRO_3 calc13() > > #define MACRO_15 (a + b)/c > > > > > > now, all throughout the codebase, whenever and whichever of MACRO_1, > > or MACRO_2 (or so forth) needs to be called, they are conveniently > > "indexed" by another macro expansion: > > > > #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) > > CONCAT(a, b) > > > > #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, N) > > > > now, if we use MASTER_MACRO with a "direct" value: > > > > MASTER_MACRO(10) or #define N 10 MASTER_MACRO(10) both > > will work. > > > > > > but substitute this with: > > > > #define N ((5*a)/c + (10*b)/c + >
Re: a nifty feature for c preprocessor
On 28 December 2011 20:57, R A wrote: > > templates, i have no problem with, i wish there could be a C dialect that can > integrate it, so i wouldn't have to be forced to use C++ and all the bloat > that usually come from a lot of it's implementation (by that i mean a > performance close to C i think is very possible for C++'s library). What "bloat"? If you only use the subset of C++ that is compatible with C++ then you don't get any additional cost, you are not "forced" to use anything, or to get any mythical "bloat" > but, of course, one has to ask "if you're making your code portable to any C > compiler, why do you want gcc to change (or modify it for your own use)? you > should be persuading the c committee." > well, that's the thing, it's harder to do the latter, so by doing this, i can > demonstrate that it's a SIMPLE, but good idea. It's not simple, or IMHO a good idea.
Re: a nifty feature for c preprocessor
On 28 December 2011 21:06, Jonathan Wakely wrote: > On 28 December 2011 20:57, R A wrote: >> >> templates, i have no problem with, i wish there could be a C dialect that >> can integrate it, so i wouldn't have to be forced to use C++ and all the >> bloat that usually come from a lot of it's implementation (by that i mean a >> performance close to C i think is very possible for C++'s library). > > What "bloat"? If you only use the subset of C++ that is compatible > with C++ Oops, I meant the subset that is compatible with C.
Re: a nifty feature for c preprocessor
On 28/12/11 21:57, R A wrote: yes, i do realize that c preprocessor is but a text substitution tool from days past when programmers where only starting to develop the rudimentaries of high-level programming. but the reason i'm sticking with the c preprocessor if the fact that code that i write from it is extremely portable. copy the code and you can use it in any IDE or stand-alone compiler, it's as simple as that. i have considered using gnu make, writing scripts with m4 and other parsers or lexers, but sticking with the preprocessor's minimalism is still too attractive an idea. If you want portable, use features that already exist. Lots of people write lots of C code that is portable across huge ranges of compilers and target processors. And if you want portable pre-processing or code generation, use something that generates the code rather than inventing tools and features that don't exist, nor will ever exist. It is also quite common to use scripts in languages like perl or python to generate tables and other pre-calculated values for inclusion in C code. about the built in features in c and C++ to alleviate the extensive use for the preprocessor, like inline functions, static consts. the fact is NOT ALL compilers out there would optimize a function so that it will not have to use a return stack. simply using a macro FORCES the compiler to do so. the same goes for static const, if you use a precompiled value, you are forcing an immediate addressing, something of a good optimization. so it's still mostly an issue of portability of optimization. Most modern compilers will do a pretty reasonable job of constant propagation and calculating expressions using constant values. And most will apply "inline" as you would expect, unless you intentionally hamper the compiler by not enabling optimisations. Using macros, incidentally, does not "FORCE" the compiler to do anything - I know at least one compiler that will take common sections of code (from macros or "normal" text) and refactor it artificial functions, expending stack space and run time speed to reduce code size. And "immediate addressing" is not necessarily a good optimisation - beware making generalisations like that. Let the compiler do what it is good at doing - generating optimal code for the target in question - and don't try to second-guess it. You will end up with bigger and slower code. templates, i have no problem with, i wish there could be a C dialect that can integrate it, so i wouldn't have to be forced to use C++ and all the bloat that usually come from a lot of it's implementation (by that i mean a performance close to C i think is very possible for C++'s library). C++ does not have bloat. The only feature of C++ that can occasionally lead to larger or slower code, or fewer optimisations, than the same code in C is exceptions - if you don't need them, disable them with "-fno-exceptions". Other than that C++ is zero cost compared to C - you only pay for the features you use. but, of course, one has to ask "if you're making your code portable to any C compiler, why do you want gcc to change (or modify it for your own use)? you should be persuading the c committee." well, that's the thing, it's harder to do the latter, so by doing this, i can demonstrate that it's a SIMPLE, but good idea. It's not a good idea, and it would not be simple to implement. I really don't want to discourage someone from wanting to contribute to gcc development, but this is very much a dead-end idea. I applaud your enthusiasm, but keep a check on reality - you are an amateur just starting C programming. C has been used for the last forty years - with gcc coming up for its 25th birthday this spring. If this idea were that simple, and that good, it would already be implemented. As you gain experience and knowledge with C (and possibly C++), you will quickly find that a preprocessor like you describe is neither necessary nor desirable. mvh., David Date: Wed, 28 Dec 2011 10:57:28 +0100 From: da...@westcontrol.com To: ren_zokuke...@hotmail.com CC: gcc@gcc.gnu.org Subject: Re: FW: a nifty feature for c preprocessor On 28/12/2011 07:48, R A wrote: i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an "evaluation" feature. I think you have missed the point about the C pre-processor. It is not a "metaprogramming" language - it is a simple text substitution macro processor. It does not have any understanding of the symbols (except for "#") in the code, nor does it support recursion - it's pure text substitution. Your suggestion would therefore need a complete re-design of the C pre-processor. And the result is not a feature that people wou
RE: a nifty feature for c preprocessor
> And if you want portable pre-processing or code generation, use > something that generates the code rather than inventing tools and > features that don't exist, nor will ever exist. It is also quite common > to use scripts in languages like perl or python to generate tables and > other pre-calculated values for inclusion in C code. though there are things that i will not disclose, i've never had to invent any tools for the project i'm working on everything is legit. this is the only time that i've had to. so believe me if i said i've considered all *conventional* solutions > Most modern compilers will do a pretty reasonable job of constant > propagation and calculating expressions using constant values. And most > will apply "inline" as you would expect, unless you intentionally hamper > the compiler by not enabling optimisations. Using macros, incidentally, > does not "FORCE" the compiler to do anything - I know at least one > compiler that will take common sections of code (from macros or "normal" > text) and refactor it artificial functions, expending stack space and > run time speed to reduce code size. And "immediate addressing" is not > necessarily a good optimisation - beware making generalisations like > that. Let the compiler do what it is good at doing - generating optimal > code for the target in question - and don't try to second-guess it. You > will end up with bigger and slower code. i'm not one to share techniques/methodologies, 1) but if it's the case for more than, say 70%, of systems/processors and 2) it takes very little penalty; then i'd write it that way. if it's not optimized, just let the compiler (if it's as good as you say it is) re-optimize it. if the compiler ain't good enough to do that, well it's not a good compiler anyway. but the code will still work. > I really don't want to discourage someone from wanting to contribute to > gcc development, but this is very much a dead-end idea. I applaud your > enthusiasm, but keep a check on reality - you are an amateur just > starting C programming. C has been used for the last forty years - with > gcc coming up for its 25th birthday this spring. If this idea were that > simple, and that good, it would already be implemented. As you gain > experience and knowledge with C (and possibly C++), you will quickly > find that a preprocessor like you describe is neither necessary nor > desirable. you know there's no way i can't answer that without invoking the wrath of the community.
FW: a nifty feature for c preprocessor
sorry: 2) it takes very little penalty, otherwise.
Re: a nifty feature for c preprocessor
that all being said, i really don't think it's a hard feature to implement like i said, just whenever there is an 1) evaluation in the conditional directives or 2) #define is called, look for "eval", if there, evaluate the expression, then substitute token. the rest of the needs no tampering at all. libccp's implementation is great, neatly divided. probably have to edit only half a dozen files, at most -- at least from what i can tell from scanning the the code. it'll just take me a long time to know how to work with setting all the flags, attributes, and working with the structs, so it's hard for me to do by myself.
