RE: a nifty feature for c preprocessor
i meant "general purpose" macro processor. sorry.
RE: a nifty feature for c preprocessor
--- > Date: Thu, 29 Dec 2011 16:30:04 -0800 > Subject: Re: a nifty feature for c preprocessor > From: james.denn...@gmail.com > To: david.br...@hesbynett.no > CC: ren_zokuke...@hotmail.com; gcc@gcc.gnu.org . > > I'd tend to agree; we ought to move functionality _out_ of the > preprocessor, not into it. > > -- James honestly, i'm not against the idea of mandating m4, or any macro processor, with every C compiler. if it improves compatibility with everyone, then i'm in... (but that would be TOO FAR ahead).
FW:
for some reason they blocked my very last email, but i tried CC'ing it again, maybe this time they'll let it through. i'm forwarding it to you, since we agree on some points. if it doesn't make it to the mailing list, you might want to forward it, then... or not. thnx > From: ren_zokuke...@hotmail.com > To: david.br...@hesbynett.no; i...@google.com > CC: gcc@gcc.gnu.org > Subject: > Date: Thu, 29 Dec 2011 14:42:08 -0800 > > > ok, for typing convenience and that they raise similar questions, i will > answer them both in the same email. > > > > From: david.br...@hesbynett.no > > You want to allow the evaluation of symbols and expressions by the > > preprocessor - > > that means it has to understand the syntax and semantics of these > > expressions, rather than just doing simple text manipulation. And it > > leads to more questions when macros and expressions are mixed - when do > > you do "evaluation", and when do you do simple text expansion? How do > > you write macros that have the "eval" function in them? > > the "eval" directive is nothing more but a proposed name. when a new feature > is drafted, it gets renamed, say "__eval_value__()", so there is less > likelihood for a conflict to arise. the possibility of it is still possible, > but that's the chance you take when you add a new feature. it's been done > over and over, not only in gcc, but also in standard C. > > > > > From: i...@google.com > > You are proposing a scheme in which the preprocessor can evaluate > > expressions and convert them back to strings. What are the types of the > > numbers in the expressions? What happens when they overflow? If the > > expressions use floating point values, are the floating point values > > in the host format or the target format? When converting a floating > > point value back to a string, what technique is used? Do we want to > > ensure that all preprocessors will get the same result? Or do we want > > to use values appropriate for the host? Or do we want to use values > > appropriate for the target? > > > > From: david.br...@hesbynett.no > > There is no standard environment for C. Should calculations be done as > > 32-bit integer? What about targets that use 16-bit integers (or even > > 64-bit integers)? You want to call the function "eval" - what about > > existing code that uses the word "eval", either as a pre-processor macro > > or as part of the C code? You want to allow recursive macros - that > > opens a wide range of problems for getting consistency and clear > > definitions (and typically requires being able to define macros in at > > least two different ways - one recursive, one literal). > > > I don't expect or want any answers here - I don't think anybody is > > looking for a discussion aiming to implement the eval idea. I just want > > to point out that there are many, many questions involved here before > > anyone could even think about implementing it. And I don't think they > > could be resolved in a way that is consistent, practical, and adds > > anything to C or the C pre-processor that is not better handled by an > > external code generator or an independent macro language. No one wants > > to re-invent the wheel. > > > good questions, but i'm surprised that you don't know basic semantics of how > the cpp works. i take it that you don't use it as extensively as others?? > anyways, the c preprocessor DOES understand arithmetic expressions, how else > would conditional expressions evaluate? > > example: > > #define N (A + 3)/2 > #if N < 10 > > without looking at the implementation details of any specific compiler, this > inherently necessitates that the cpp inherently understand the meaning -- > it's something fundamental. though by standard, this doesn't necessarily > substitutes the value of the evaluated N. > > in regards to floating points and overflows, i would like to remind ian that > floats have never never had to be understood by cpp. yes, there are pragmas > to handle them, but in it's own textual way. that's why you can never use a > float in any conditional directive. defining them on their own, of course, is > permitted, as it gets directly substituted. > > overflows are not an issue. the limit to how large a number can be calculated > by the preprocessor (say for conditionals) is implementation specific, and > yes the C standard does define minimum limits. but after it does all it's, to > the final preprocessed code, it simply substitute the evaluated value (if > we're lucky) or simply substitute an equivalent expression. it's the > compiler's job then to decide how to finally evaluate it, what type size is > it and if it went overflow. basically what i'm trying to say is whatever > value the eval evaluates to, it is always within the bounds of the cpp. you > can then lay the blame
Re: a nifty feature for c preprocessor
On Thu, Dec 29, 2011 at 1:50 PM, David Brown wrote: > On 29/12/11 22:05, R A wrote: >> >> >>> The gcc developers, and everyone else involved in the development >>> of C as a language, are perhaps not superhuman - but I suspect >>> their combined knowledge, experience and programming ability >>> outweighs yours. >> >> >> given. but do you have a consensus of the community that this feature >> is not worth including? i haven't even heard but from a few people >> saying that "it's not worth it because if it was, 'we're the ones to >> have thought about it'". >> >> computing science (may i call it a science??), is all about >> objectivity and examining the theories and evidence. it should be >> prepared re-examine everything when a new idea is introduced or >> challenged. >> >> so if it's a bad idea, explain to me exactly why; not go about human >> politics. >> > > I don't speak for the gcc community - either for the users or the > developers. But occasionally I can help out on this mailing list, and let > the real developers get on with their work. > > There are a number of reasons why you wouldn't want an evaluation system as > part of the C preprocessor (disregarding any thoughts about it being hard to > do, impossible to standardise, and redundant given all the other ways to > achieve the same ends). The C preprocessor already includes evaluation of expressions, for conditional inclusion... > There is no standard environment for C. Should calculations be done as > 32-bit integer? What about targets that use 16-bit integers (or even 64-bit > integers)? They can use the same rules they use today, no? This is already standardized. > You want to call the function "eval" - what about existing code > that uses the word "eval", either as a pre-processor macro or as part of the > C code? You want to allow recursive macros - that opens a wide range of > problems for getting consistency and clear definitions (and typically > requires being able to define macros in at least two different ways - one > recursive, one literal). You want to allow the evaluation of symbols and > expressions by the preprocessor - that means it has to understand the syntax > and semantics of these expressions, rather than just doing simple text > manipulation. The C preprocessor mostly manipulates tokens, not plain text. > And it leads to more questions when macros and expressions > are mixed - when do you do "evaluation", and when do you do simple text > expansion? How do you write macros that have the "eval" function in them? I certainly see problems with the "eval" proposal, both technical and otherwise. Technically, we could deal with it in much the same way as the "defined" preprocessing operator. Non-technically, the preprocessor is "the wrong place" for this functionality. > I don't expect or want any answers here - I don't think anybody is looking > for a discussion aiming to implement the eval idea. I just want to point > out that there are many, many questions involved here before anyone could > even think about implementing it. And I don't think they could be resolved > in a way that is consistent, practical, and adds anything to C or the C > pre-processor that is not better handled by an external code generator or an > independent macro language. No one wants to re-invent the wheel. I'd tend to agree; we ought to move functionality _out_ of the preprocessor, not into it. -- James
Re: none
(Sorry for the double reply back, I should have read ahead). R A writes: > good questions, but i'm surprised that you don't know basic semantics of how > the cpp works. i take it that you don't use it as extensively as others?? Thank for the patronizing words. That is always a good way to get people on your side. > anyways, the c preprocessor DOES understand arithmetic expressions, how else > would conditional expressions evaluate? But it doesn't convert them back to strings. > in regards to floating points and overflows, i would like to remind ian that > floats have never never had to be understood by cpp. yes, there are pragmas > to handle them, but in it's own textual way. that's why you can never use a > float in any conditional directive. defining them on their own, of course, is > permitted, as it gets directly substituted. Are you suggesting that floats not be permitted in the expressions which can be evaluated in your proposed extension? That would indeed simplify matters. > overflows are not an issue. the limit to how large a number can be calculated > by the preprocessor (say for conditionals) is implementation specific, and > yes the C standard does define minimum limits. but after it does all it's, to > the final preprocessed code, it simply substitute the evaluated value (if > we're lucky) or simply substitute an equivalent expression. it's the > compiler's job then to decide how to finally evaluate it, what type size is > it and if it went overflow. basically what i'm trying to say is whatever > value the eval evaluates to, it is always within the bounds of the cpp. you > can then lay the blame on cpp, not the extra eval. Yeah, actually I was wrong here, I see that in C99 (but not C90) the preprocessor types are now specified in target terms. Integers are always intmax_t or uintmax_t. So it would theoretically be possible to specify floating point (if permitted by your extension) as using the target type. I don't know what effect that would have on C99 conforming compilers, possibly none. There would still be an issue with floating point (if permitted) in that it would be necessary to either specify the conversion to string or to accept that the program would differ on different hosts. > it's always easy to get carried away with your emotion when you've been > "outsaid", and in an attempt to redeem oneself, come up with the cleverest > responses that was very little thought of. let's all maintain a good > discussion. Ah, more patronizing words, how nice. Ian
Re: a nifty feature for c preprocessor
R A writes: >> This particular extension seems problematic when cross-compiling. In >> what environment should the expressions be evaluated? > > > why > are you asking for a specific environment? it's coding convenience and > elegance for coding in c itself. simplest case scenario is what i've > already mentioned in my very first email. You are proposing a scheme in which the preprocessor can evaluate expressions and convert them back to strings. What are the types of the numbers in the expressions? What happens when they overflow? If the expressions use floating point values, are the floating point values in the host format or the target format? When converting a floating point value back to a string, what technique is used? Do we want to ensure that all preprocessors will get the same result? Or do we want to use values appropriate for the host? Or do we want to use values appropriate for the target? We can invent answers for these questions but I don't see any obvious answers. Some of the answers would impose significant amounts of extra implementation work for any C compiler. Hence, the extension is problematic. Ian
Re: a nifty feature for c preprocessor
On 29/12/11 22:05, R A wrote: The gcc developers, and everyone else involved in the development of C as a language, are perhaps not superhuman - but I suspect their combined knowledge, experience and programming ability outweighs yours. given. but do you have a consensus of the community that this feature is not worth including? i haven't even heard but from a few people saying that "it's not worth it because if it was, 'we're the ones to have thought about it'". computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics. I don't speak for the gcc community - either for the users or the developers. But occasionally I can help out on this mailing list, and let the real developers get on with their work. There are a number of reasons why you wouldn't want an evaluation system as part of the C preprocessor (disregarding any thoughts about it being hard to do, impossible to standardise, and redundant given all the other ways to achieve the same ends). There is no standard environment for C. Should calculations be done as 32-bit integer? What about targets that use 16-bit integers (or even 64-bit integers)? You want to call the function "eval" - what about existing code that uses the word "eval", either as a pre-processor macro or as part of the C code? You want to allow recursive macros - that opens a wide range of problems for getting consistency and clear definitions (and typically requires being able to define macros in at least two different ways - one recursive, one literal). You want to allow the evaluation of symbols and expressions by the preprocessor - that means it has to understand the syntax and semantics of these expressions, rather than just doing simple text manipulation. And it leads to more questions when macros and expressions are mixed - when do you do "evaluation", and when do you do simple text expansion? How do you write macros that have the "eval" function in them? I don't expect or want any answers here - I don't think anybody is looking for a discussion aiming to implement the eval idea. I just want to point out that there are many, many questions involved here before anyone could even think about implementing it. And I don't think they could be resolved in a way that is consistent, practical, and adds anything to C or the C pre-processor that is not better handled by an external code generator or an independent macro language. No one wants to re-invent the wheel.
LTO multiple definition failures
I've been investigating some LTO-related test failures in a GCC port for a DSP target that has not yet been submitted to the FSF. The bug I've hit looks like the same issue with spurious multiple definitions that was previously reported on the gcc-help list: http://gcc.gnu.org/ml/gcc-help/2011-10/msg00201.html for an ARM EABI target with RTEMS. I've been trying to duplicate the failure with some other target that can be tested "off the shelf". I haven't found an actual failure yet, but I think I see what is causing it. Here's the analysis I came up with using a powerpc-none-eabi target. I added some instrumentation to ld to make it print out the files it was loading from the output of the LTO plugin. Building powerpc-none-eabi-gcc /scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c /scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c /scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O2 -flto -msim -lm -save-temps -Wl,-Map=foo.map told me: Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/ecrti.o OPEN_BFD_NORMAL Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/sim-crt0.o OPEN_BFD_NORMAL Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/crtbegin.o OPEN_BFD_NORMAL Loading 20010124-1.o OPEN_BFD_NORMAL Loading 20010124-1-lib.o OPEN_BFD_NORMAL Loading main.o OPEN_BFD_NORMAL Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libm.a OPEN_BFD_NORMAL Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/libgcc.a OPEN_BFD_NORMAL =start group Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libsim.a OPEN_BFD_FORCE Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libc.a OPEN_BFD_FORCE =end group Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/libgcc.a OPEN_BFD_NORMAL Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/crtend.o OPEN_BFD_NORMAL Loading /scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/ecrtn.o OPEN_BFD_NORMAL Loading /tmp/ccxgHMEr.ltrans0.ltrans.o OPEN_BFD_NORMAL Note that this last file includes a local definition of memcpy, originally from 20010124-1-lib.c. The thing that seems to be leading to the multiple definition error is that the startup code for my target, and apparently the startup code for the RTEMS target too, includes a reference to memcpy, which is resolved to the version from libc.a *before* the linker sees the one from the *.ltrans.o file at the end of the list. I'm still finding my way around LTO; can anyone who's more familiar with this help narrow down where to look for the cause of this? I don't even know if this is a compiler or ld bug at this point. I'm not sure I can justify spending a lot of time working on this, but I'd at least like to get a proper bug report with an easily reproducible test case filed in the appropriate Bugzilla. I looked around and didn't see that the previous report of this bug on gcc-help@ ended up recorded anyplace that the LTO gurus were likely to remember or do anything about it. :-S -Sandra
RE: a nifty feature for c preprocessor
> I personally do not feel it is worth the effort. It's easy to use a > more powerful macro processor, such as m4, to generate your C code. The > benefit of building a more powerful macro processor into the language > proper seems minimal. > > This particular extension seems problematic when cross-compiling. In > what environment should the expressions be evaluated? why are you asking for a specific environment? it's coding convenience and elegance for coding in c itself. simplest case scenario is what i've already mentioned in my very first email. alright, i'll repeat myself (in case you haven't read the whole thread)... say you have different macros, FUNC_MACRO1, FUNC_MACRO2, FUNC_MACRO3, ... whichever macro to be used can be indexed 1, 2, 3... so forth. the index is conveniently described in an arithmetic expression, as it usually arises even if just programming in plain c. #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) CONCAT(a, b) #define FUNC_MACRO(N) CONCAT_VAR(FUNC_MACRO_, N) invoking with FUNC_MACRO(1), FUNC_MACRO(2), so forth... will work. but like i said, it's usually described by an arithmetic macro expression. so if you have this: #define N a + b/c and use it later on: FUNC_MACRO(N), will expand to: FUNC_MACRO_a + b/c which is wrong. it alleviates the need to write external files in, say, m4, even if the macro is just a few lines long; and having to go back and forth with another language (for us novices).
RE: a nifty feature for c preprocessor
> given. but do you have a consensus of the community that this > feature is not worth including? i haven't even heard but from a few > people saying that "it's not worth it because if it was, 'we're the > ones to have thought about it'". No, that's not what people are saying. It's important to take a high-level view of programming language design, including the role of the "community". As Robert pointed out, proposals look a lot different when you get down into the details. One of the most complex issues in programming language design is the interaction between features. You can often have two features that seems quite simple individually, but have quite complex interactions. As Ian says in a later message, one issue with your proposal is that of how it interacts with cross-compilation. The hard part of programming language design isn't to come up with ideas for what to add to a programming language, since there are always dozens of them, but which ones make sense to add. For example, strict typing and built-in range checking are well-understood to be important language features, especially for safety-critical environments. But nobody would suggest adding them to every programming language. Deciding which things to add to a language isn't generally done by looking at whether the thing is a "good idea" or even if it's "useful to the community", but by looking at the effect that adding it would have on the language overall. A large part of that takes into account the complexity and culture of the language. A language like C is meant to be very simple, with very few features. That's why there have been so few new features added to it in recent decades. On the other side, a language like Ada has numerous features, so every five years or so, a number of new features get added. But even there, significant care has to be taken as to what makes it in: many good ideas don't. In order to consider adding a new feature to a programming language, especially one like C that's been so stable over recent decades, the threshold is FAR higher than that the feature be "useful" or "nifty". What you're hearing, from some of the best people in the world to make such a statement, is that what you propose doesn't come close to that threshold. You need to accept that. > computing science (may i call it a science??), is all about objectivity > and examining the theories and evidence. it should be prepared re-examine > everything when a new idea is introduced or challenged. You are confusing programming language design with CS research. There are hundreds (if not thousands) of ideas from other programming language which are quite well accepted as valuable. But that doesn't mean that it makes sense to add any of them to the C programming language.
Re: a nifty feature for c preprocessor
The idea sounds useful to me .. Or perhaps introduce template into C :) David On Thu, Dec 29, 2011 at 1:12 PM, Ian Lance Taylor wrote: > R A writes: > >>> The gcc developers, and everyone else involved in the development of C >>> as a language, are perhaps not superhuman - but I suspect their combined >>> knowledge, experience and programming ability outweighs yours. >> >> given. but do you have a consensus of the community that this feature is not >> worth including? i haven't even heard but from a few people saying that >> "it's not worth it because if it was, 'we're the ones to have thought about >> it'". >> >> computing science (may i call it a science??), is all about objectivity and >> examining the theories and evidence. it should be prepared re-examine >> everything when a new idea is introduced or challenged. >> >> so if it's a bad idea, explain to me exactly why; not go about human >> politics. >> > > Any gcc developer who feels that this proposal is a good idea, please > chime in here. > > I personally do not feel it is worth the effort. It's easy to use a > more powerful macro processor, such as m4, to generate your C code. The > benefit of building a more powerful macro processor into the language > proper seems minimal. > > This particular extension seems problematic when cross-compiling. In > what environment should the expressions be evaluated? > > Ian
Re: a nifty feature for c preprocessor
R A writes: >> The gcc developers, and everyone else involved in the development of C >> as a language, are perhaps not superhuman - but I suspect their combined >> knowledge, experience and programming ability outweighs yours. > > given. but do you have a consensus of the community that this feature is not > worth including? i haven't even heard but from a few people saying that "it's > not worth it because if it was, 'we're the ones to have thought about it'". > > computing science (may i call it a science??), is all about objectivity and > examining the theories and evidence. it should be prepared re-examine > everything when a new idea is introduced or challenged. > > so if it's a bad idea, explain to me exactly why; not go about human politics. > Any gcc developer who feels that this proposal is a good idea, please chime in here. I personally do not feel it is worth the effort. It's easy to use a more powerful macro processor, such as m4, to generate your C code. The benefit of building a more powerful macro processor into the language proper seems minimal. This particular extension seems problematic when cross-compiling. In what environment should the expressions be evaluated? Ian
RE: a nifty feature for c preprocessor
> The gcc developers, and everyone else involved in the development of C > as a language, are perhaps not superhuman - but I suspect their combined > knowledge, experience and programming ability outweighs yours. given. but do you have a consensus of the community that this feature is not worth including? i haven't even heard but from a few people saying that "it's not worth it because if it was, 'we're the ones to have thought about it'". computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics.
Re: fixed_scalar_and_varying_struct_p and varies_p
> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM. > So in these cases fixed_scalar_and_varying_struct_p effectively becomes > a no-op on targets that don't allow MEMs in addresses and takes on > suspicious semantics for those that do. In the former case, every > address is treated as "unvarying" and f_s_a_v_s_p always returns null. > In the latter case, things like REG addresses are (wrongly) treated as > unvarying while a MEM address might correctly be treated as varying, > leading to false positives. > > It looks like this goes back to when fixed_scalar_and_varying_struct_p > was added in r24759 (1999). Does this mean that MEM_IN_STRUCT_P and MEM_SCALAR_P have also been effectively disabled since then? > AIUI, the true_dependence varies_p parameter exists for the benefit > of CSE, so that it can use its local cse_rtx_varies_p function. > All other callers should be using rtx_varies_p instead. Question is, > should I make that change, or is it time to get rid of > fixed_scalar_and_varying_struct_p instead? I'd vote for the latter (and for eliminating MEM_IN_STRUCT_P and MEM_SCALAR_P in the process, if the answer to the above question is positive), there is no point in resurrecting this now IMO. -- Eric Botcazou
xlr/xlp __atomic builtins using ldadd and swap
Richard, I'm interested in implementing (some of) the new __atomic builtins using the xlr/xlp atomic instructions ldadd and swap. Do you perhaps have work in progress there? Thanks, - Tom
Lingering tbaa in anti_dependence?
AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
anti_dependence between a load X and store Y because Y might be defining
a new object in the same space as the object that was being read by X.
But it looks like we still use component-based disambiguation
(nonoverlapping_component_refs_p) in this case. Is it true that
that's also a problem? E.g. for:
struct s { int f; float g; };
struct t { int header; struct s s; };
float foo (struct t *newt, struct s *olds, int x, int y)
{
float ret = olds[x * y].g;
newt->header = 0;
newt->s.f = 1;
newt->s.g = 1.0;
return ret;
}
we can (and on ARM Cortex A8, do) move the store to newt->s.f above
the load from olds[...].g. If we view the assignment to newt
as defining a new object in the same space as the now-defunct olds,
and if x * y happens to be zero, then the accesses might well be
to the same address.
Sorry if this is already a known problem...
Richard
fixed_scalar_and_varying_struct_p and varies_p
I was looking again at:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00294.html
and was comparing the RTL {true,output,anti}_dependence functions.
output_dependence and anti_dependence call fixed_scalar_and_varying_struct_p
with rtx_addr_varies_p. Many places also call true_dependence with
rtx_addr_varies_p (which then gets passed to fixed_scalar_and_varying_struct_p).
But this doesn't seem to make much sense. rtx_addr_varies_p checks
whether an rtx X includes a MEM with a varying address, whereas
fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
So in these cases fixed_scalar_and_varying_struct_p effectively becomes
a no-op on targets that don't allow MEMs in addresses and takes on
suspicious semantics for those that do. In the former case, every
address is treated as "unvarying" and f_s_a_v_s_p always returns null.
In the latter case, things like REG addresses are (wrongly) treated as
unvarying while a MEM address might correctly be treated as varying,
leading to false positives.
It looks like this goes back to when fixed_scalar_and_varying_struct_p
was added in r24759 (1999). The anti_dependence change went from applying
rtx_addr_varies_p to the MEM to applying rtx_addr_varies_p to the address:
@@ -1234,16 +1279,25 @@ anti_dependence (mem, x)
x_addr = XEXP (x, 0);
mem_addr = XEXP (mem, 0);
- return (memrefs_conflict_p (SIZE_FOR_MODE (mem), mem_addr,
- SIZE_FOR_MODE (x), x_addr, 0)
- && ! (MEM_IN_STRUCT_P (mem) && rtx_addr_varies_p (mem)
- && GET_MODE (mem) != QImode
- && GET_CODE (mem_addr) != AND
- && ! MEM_IN_STRUCT_P (x) && ! rtx_addr_varies_p (x))
- && ! (MEM_IN_STRUCT_P (x) && rtx_addr_varies_p (x)
- && GET_MODE (x) != QImode
- && GET_CODE (x_addr) != AND
- && ! MEM_IN_STRUCT_P (mem) && ! rtx_addr_varies_p (mem)));
+ if (!memrefs_conflict_p (SIZE_FOR_MODE (mem), mem_addr,
+ SIZE_FOR_MODE (x), x_addr, 0))
+return 0;
+
+ fixed_scalar
+= fixed_scalar_and_varying_struct_p (mem, x, rtx_addr_varies_p);
+
+ return (!(fixed_scalar == mem && !aliases_everything_p (x))
+ && !(fixed_scalar == x && !aliases_everything_p (mem)));
This seems to have percolated into:
expr.c:safe_from_p
gcse.c:mems_conflict_for_gcse_p
gcse.c:compute_transp
postreload.c:find_mem_conflicts
store-motion.c:load_kills_store
which all pass rtx_addr_varies_p to true_dependence.
AIUI, the true_dependence varies_p parameter exists for the benefit
of CSE, so that it can use its local cse_rtx_varies_p function.
All other callers should be using rtx_varies_p instead. Question is,
should I make that change, or is it time to get rid of
fixed_scalar_and_varying_struct_p instead?
Richard
Re: [RFC, ARM] cortex_a8_call cost
Quoting Dmitry Melnik : Hi, In cortex-a8.md call cost is set to 32, while in cortex-a9.md it's 0: == cortex-a8.md == ;; Call latencies are not predictable. A semi-arbitrary very large ;; number is used as "positive infinity" so that everything should be ;; finished by the time of return. (define_insn_reservation "cortex_a8_call" 32 (and (eq_attr "tune" "cortexa8") (eq_attr "type" "call")) "cortex_a8_issue_branch") Obviously, if the idea is to tell the scheduler that whatever is in the pipeline now will be done with when the next instruction is executed, the resource usage is wrong. Compare this with sh4.md: ;; calls introduce a longisch delay that is likely to flush the pipelines ;; of the caller's instructions. Ordinary functions tend to end with a ;; load to restore a register (in the delay slot of rts), while sfuncs ;; tend to end with an EX or MT insn. But that is not actually relevant, ;; since there are no instructions that contend for memory access early. ;; We could, of course, provide exact scheduling information for specific ;; sfuncs, if that should prove useful. (define_insn_reservation "sh4_call" 16 (and (eq_attr "pipe_model" "sh4") (eq_attr "type" "call,sfunc")) "d_lock*16")
[RFC, ARM] cortex_a8_call cost
Hi, In cortex-a8.md call cost is set to 32, while in cortex-a9.md it's 0: == cortex-a8.md == ;; Call latencies are not predictable. A semi-arbitrary very large ;; number is used as "positive infinity" so that everything should be ;; finished by the time of return. (define_insn_reservation "cortex_a8_call" 32 (and (eq_attr "tune" "cortexa8") (eq_attr "type" "call")) "cortex_a8_issue_branch") == cortex-a9.md == ;; Call latencies are essentially 0 but make sure ;; dual issue doesn't happen i.e the next instruction ;; starts at the next cycle. (define_insn_reservation "cortex_a9_call" 0 (and (eq_attr "tune" "cortexa9") (eq_attr "type" "call")) "cortex_a9_issue_branch + cortex_a9_multcycle1 + cortex_a9_ls + ca9_issue_vfp_neon") Do these CPUs differ much? Which cost is the right one? Here's why I'm asking. In the following example, dependence cost of 32 for cortex_a8_call causes insns 464 and 575 to be separated by 308 (in spite having same priority), because 575 is not ready at tick 12, which causes generation of separate IT-blocks for them on Thumb-2. ;;<> 9--> 300 r0=call [`spec_putc']:cortex_a8_issue_branch ;;<> 9--> 306 r3=sl 0>>0x18^r8 :cortex_a8_default ;;<> 10--> 309 cc=cmp(r5,r8) :cortex_a8_default ;;<> 11--> 307 r3=[r3*0x4+r9] :cortex_a8_load_store_1 ;;<> 12--> 464 (cc) r2=0x1 :cortex_a8_default ;;<> 13--> 308 sl=sl<<0x8^r3 :cortex_a8_default ;;<> 41--> 575 (cc) [sp+0x4]=r2 :cortex_a8_load_store_1 Insn 575 has true dependency with call insn 300 on r2, which is CALL_USED_REG, and as 464 is conditional, 575 retains true dependency with 300. Setting cortex_a8_call cost to 1 saves 186 bytes on SPEC2000 INT (but I'm not sure whether it's only because of less IT-block splitting). -- Best regards, Dmitry
Re: a nifty feature for c preprocessor
On 12/28/2011 6:25 PM, R A wrote: 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. It will definitely be harder than you think. Lots of changes like this are easy enough when described at a high level of abstraction, but the implementation details are complex. And I agree with others, this is an undesirable extension to the language regardless of difficulty of implementation. 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. I discourage the effort, I don't think the result, even if you do achieve a working version, would ever be accepted. Better to spend your effort figuring out more appropriate ways to solve the problem.
Re: a nifty feature for c preprocessor
On 29/12/2011 00:08, R A wrote: 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 No, you haven't considered all conventional solutions. I've given you a couple of pointers. You are not the first person who wanted to include pre-calculated values in portable C code. 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. You are not expected to answer it - you are expected to accept it as reality. The gcc developers, and everyone else involved in the development of C as a language, are perhaps not superhuman - but I suspect their combined knowledge, experience and programming ability outweighs yours. Good luck with your project, but I strongly encourage you to find a different way to cope with your issues here. Work /with/ your tools, not against them.
RE: A case exposing code sink issue
> -Original Message-
> From: Jiangning Liu
> Sent: Wednesday, December 28, 2011 5:38 PM
> To: Jiangning Liu; 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: 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?
>
It seems many people are still in the happy of the upcoming 2012 New Year.
:-)
Following my story, I find the following code in tree-ssa-copy.c
/* Avoid copy propagation from an inner into an outer loop.
Otherwise, this may move loop variant variables outside of
their loops and prevent coalescing opportunities. If the
value was loop invariant, it will be hoisted by LICM and
exposed for copy propagation.
??? The value will be always loop invariant.
In loop-closed SSA form do not copy-propagate through
PHI nodes in blocks with a loop exit edge predecessor. */
if (current_loops
&& TREE_CODE (arg_value) == SSA_NAME
&& (loop_depth_of_name (arg_value) > loop_depth_of_name (lhs)
|| (loops_state_satisfies_p (LOOP_CLOSED_SSA)
&& loop_exit_edge_p (e->src->loop_father, e
{
phi_val.value = lhs;
break;
}
Here http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00066.html, Dan said
"The original check was not because of coalescing, but because we would
copy prop in-loop variables outside the loop, causing *more*
invariantness in nested loops."
Can anybody give me a concrete example to explain this statement?
Anyway, for my simple case, I don't see bad thing would happen when
propagate &a[i] out of the loop. Also, after this propagation, "a_p.0_4 =
&a[i_13];" within the loop would be dead code and removed in the passes
afterwards. In my opinion, that way the computation would be reduced in the
loop. Did I make any mistake?
> > Thanks,
> > -Jiangning
> >
> >
> >
>
>
