Creating a structure at compile time.
I am working on a gcc-plugin where I need to create a structure at compile time. I have gleaned over one of the front ends to learn more about creating structures at compile time. What I have thus far is a type node for my struct. I now need to create an instance of this struct. For exemplary purposes we will call this type 'struct T' and we will call the instance of T, 'my_T' By using the build_constructor() routine in GCC I create an instance, my_T, which I need to pass the address of to a function. So, I take this decl, my_T, and pass it to build_fold_addr_expr(). The result of the latter is what I pass to the function 'fn()'. Yes, the function I am passing the reference to is expecting the proper type, that of address-to-T. Running this presents me with an error in expand_expr_real_1() where "Variables inherited from containing functions should have been lowered by this point." So, I figure, if I create a temp variable, 'V', of type pointer-to-T, and run make_ssa_name() on that temp. And then insert an assignment before the call to fn, so I get: 'V = &my_T;' After looking at the GIMPLE dump, I see, 'V = &my_T; fn(V);' Which is correct, however, in the type list of the caller, I only see: 'struct * V;' Now, this concerns me, I would expect to see "struct T *V;" As above, this case also fails. I am baffled, do I need to even be creating the ssa_name instance to pass to 'fn()', which is 'V' in the case above? Or, will the build_constructor() produce a tree node that I can treat as a variable, that I can pass to 'fn()' ? -Matt
Simplification of relational operations (was [patch for PR18942])
Zdenek,
I'm looking at a missed optimizations in combine and it is similar to the one
you've fixed in PR18942 (http://thread.gmane.org/gmane.comp.gcc.patches/81504).
I'm trying to make GCC optimize
(leu:SI
(plus:SI (reg:SI) (const_int -1))
(const_int 1))
into
(leu:SI
(reg:SI)
(const_int 2))
.
Your patch for PR18942 handles only EQ/NE comparisons, and I wonder if there is
a reason not to handle LEU/GEU, LTU/GTU comparisons as well. I'm a bit fuzzy
whether signed comparisons can be optimized here as well, but I can't see the
problem with unsigned comparisons.
Any reason why this optimization would be unsafe?
Regarding the testcase, the general pattern
(set (tmp1) (plus:SI (reg:SI) (const_int A))
(set (tmp2) (leu:SI (tmp1) (const_int B))
is generated from switch statement
switch (reg) {
case A:
case B:
...
}
Combine tries merge the two instructions into one, but fails. This causes an
extra 'add' instruction per switch statement in the final assembly. The target
I'm working with is MIPS, but, I imagine, other architectures are affected as
well.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
RE: A case exposing code sink issue
> -Original Message- > From: Michael Matz [mailto:m...@suse.de] > Sent: Monday, November 28, 2011 9:07 PM > To: Jiangning Liu > Cc: gcc@gcc.gnu.org > Subject: RE: A case exposing code sink issue > > Hi, > > On Mon, 28 Nov 2011, Jiangning Liu wrote: > > > > > One more question... > > > > > > > > Can " i = i.6_18;" be sinked out of loop, because it doesn't have > > > memory > > > > dependence with others? > > > > > > With current trunk the stores to i, a_p, b_p and k are sunken after > the > > > loop. (There are no aliasing problems because the decls can't > > > conflict). > > > > > > What isn't sunken is the calculation of the &a[D.2248_7] expression. > > > First, the number of iterations of the inner loop can't be > determined > > > by > > > current code (replacing i+=k with e.g. i++ could be handled for > > > instance). > > > > Hi Michael, > > > > Do you know what the essential problem is in the case of loop > iteration > > uncertainty? > > Yes, the number of iterations of the i loop simply is too difficult for > our loop iteration calculator to comprehend: > > for (i=k; i<500; i+=k) > > iterates for roundup((500-k)/k) time. In particular if the step is > non-constant our nr-of-iteration calculator gives up. So do you think this can be improved somewhere? For this case, looking at the result in middle end, "a_p.2_8 = &a[D.2248_7];" should be able to sunken out of loop. That way the computation of &a[D.2248_7] would be saved in loop, although the consequence is the liverange of D.2248_7 is longer and it needs to live out of loop. But anyway the register pressure would be decreased within the loop, and we would less possibly have spill/fill code. This is what I want. I think we can simply use loop induction variable analysis to solve this problem. Do you think so? Thanks, -Jiangning > > > I thought it was still an aliasing problem. > > No. All accesses are resolved to final objects (i.e. no pointers), and > hence can be trivially disambiguated. > > > Ciao, > Michael.
Re: Warning for functions called before declared inline
On Thu, 1 Dec 2011, Steven Bosscher wrote: > On Thu, Dec 1, 2011 at 7:42 PM, Joseph S. Myers > wrote: > > On Thu, 1 Dec 2011, Steven Bosscher wrote: > > > >> Is it valid in dialects older than C99 to declare a function static > >> inline after calling it? Should the warnings be brought back in the > >> compiler? > > > > Older dialects didn't have inline. > > Not even gnu89? Well, what's valid there is what the compiler accepts. This is unrelated to the way in which gnu89 inline semantics differ from C99, so I see no reason to reject it. > > Building with older GCC should not use -Werror; only later bootstrap > > stages, or --enable-werror-always, should do so, and > > --enable-werror-always is meant to be used for building a cross-compiler > > using the same version of GCC. > > Hm, I didn't do anything special. Just configure --target=arm-eabi, > then make. Perhaps there is an error in configure.ac. There must be. -Werror builds like that simply won't work, because of the internal diagnostic formats that 4.3's format checking doesn't understand. -- Joseph S. Myers jos...@codesourcery.com
gcc-4.5-20111201 is now available
Snapshot gcc-4.5-20111201 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111201/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 181895 You'll find: gcc-4.5-20111201.tar.bz2 Complete GCC MD5=fbb3aa801c74f67b462c235da8700c00 SHA1=94d30ce733de98d72a19fcdd093dd5fb121bc8ae Diffs from 4.5-2024 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: volatile correctness: combine vs. target.md
Georg-Johann Lay writes: > Ian Lance Taylor wrote: > >> It's a case that will never ordinarily arise. It only >> arises for you because you are specifically trying to combine a volatile >> MEM. I don't know if it makes sense for the general purpose combine to >> try to handle such an unusual special case. > > It's not unusual because: > > * It's not unusual to write down SFRs as violatile memory like > (*((volatile unsigned int*) 0x1234)) or as a cast to a composite > that reflects the SFRs bit(field)s. > > * It's not unusual that microcontrollers can access specific parts > of memory -- in particular I/O -- with special instructions. Sure. What's unusual here is using combine, not those two requirements. >> Have you tried using a peephole instead of a combine pattern? > > I don't like RTL/text peepholes. They are just a last resort to fix > stuff that wasn't optimized properly in other passes and to clean up > remains from reload. You can fight against the compiler, or you can fight on the same side as the compiler. It's your choice. > What about that predicate? > > (define_predicate "low_io_mem" >(and (match_code "mem") > (match_test "low_io_address_operand (XEXP (op, 0))"))) > > Guess it operates the same because the drag-volatile-over-volatile > happens not in recog(_for_combine) but already when combine > synthesizes new patterns. As combine juggles with data flow, it must > not exchange volatiles. That's all. The backend will know if it's ok > to place a specific operand into a specific insn or not. > > And skipping optimizations like these altogether because they are > uncomfortable to handle is the wrong direction, IMHO. OK, what is your proposed patch to combine? Maybe it is easy to make it do what you want. I haven't looked. Ian
Re: volatile correctness: combine vs. target.md
Ian Lance Taylor wrote: Georg-Johann Lay writes: If general_operand can be perceived as (define_predicate "general_operand" (ior (match_operand 0 "memory_operand") (match_operand 0 "register_operand") (match_operand 0 "immediate_operand"))) how can low_io_mem ever match? Oh, I see, I did misunderstand your question. Sorry about that. In general combine is just going to honor what your backend is asking for. If your backend says that it is OK to combine a volatile memory operand, then that is what combine is going to do. Supplying an insn is the backend's way of telling that it is capable of performing a specific operation. In the present case, the backend tells that it has a "Conditional Jump depending on a bit in the I/O area". It does *not* say "It is ok to infringe volatile correctness" and move one volatile memory access across an other one or similar memory annotation like memory clobber by means of inline assembly or built-in barrier. It's certainly OK in general to combine across a volatile memory operand, as is happening here. I guess you are asking whether combine should have another check: if some operand in the insn is a volatile MEM, and it will cross a volatile MEM not mentioned in the combine, should combine reject that combination. It's never correct to exchange volatile accesses. It's a case that will never ordinarily arise. It only arises for you because you are specifically trying to combine a volatile MEM. I don't know if it makes sense for the general purpose combine to try to handle such an unusual special case. It's not unusual because: * It's not unusual to write down SFRs as violatile memory like (*((volatile unsigned int*) 0x1234)) or as a cast to a composite that reflects the SFRs bit(field)s. * It's not unusual that microcontrollers can access specific parts of memory -- in particular I/O -- with special instructions. And then: combine does not operate in empty space ;-) Just like other general purpose parts of the compiler that have to care for exceptions for this hardware here and that hardware there like in reload, in scheduler, and many other places. BTW, I see this bug only with 4.6. 4.7 does not combine across the volatile access. But it also fails to combine the jump-on-I/O-bit if the load from I/O immediately preceedes the conditional jump-on-bit. Didn't yet look into that. Have you tried using a peephole instead of a combine pattern? Ian I don't like RTL/text peepholes. They are just a last resort to fix stuff that wasn't optimized properly in other passes and to clean up remains from reload. In this case, a jump-on-I/O-bit does not require a register whereas loading and then jump-on-bit-in-register will allocate a register even though it's optimized out after relaod. And if reload has fun and spills for some reason, peephole will never get a chance to fix it. For setting a bit in I/O it's even worse. This can be accomplisheb by one instruction and is an atomic operation. A load-bitop-write operation, however, is no more atomic and requires a register of a special class to perform bitop. In order to get it atomic again, you'd have to turn IRQs off which makes it even more costly up to factor of 6 because it is slower, more code, needs a scratch to store the interrupt-flag and increases IRQ respond times. What about that predicate? (define_predicate "low_io_mem" (and (match_code "mem") (match_test "low_io_address_operand (XEXP (op, 0))"))) Guess it operates the same because the drag-volatile-over-volatile happens not in recog(_for_combine) but already when combine synthesizes new patterns. As combine juggles with data flow, it must not exchange volatiles. That's all. The backend will know if it's ok to place a specific operand into a specific insn or not. And skipping optimizations like these altogether because they are uncomfortable to handle is the wrong direction, IMHO. Johann
Parallel build error
For the past couple of years I've simply ignored these problems by ritually adding 'echo .NOTPARALLEL: >> Makefile' to my top-level issue-the-long-configure-option scripts. But I suppose the reason why these never get fixed is no one reporting... This one happened shockingly early. $ make -j4 all-stage1 make[1]: Entering directory `/home/rth/work/gcc/bld-nat' make[1]: Entering directory `/home/rth/work/gcc/bld-nat' make[1]: Entering directory `/home/rth/work/gcc/bld-nat' make[1]: Entering directory `/home/rth/work/gcc/bld-nat' mkdir: cannot create directory `stage1-gcc': File exists mv: cannot move `stage1-gcc' to `gcc': No such file or directory make[1]: *** [stage1-start] Error 1 make[1]: Leaving directory `/home/rth/work/gcc/bld-nat' make: *** [configure-stage1-libiberty] Error 2 make: *** Waiting for unfinished jobs r~
Re: Warning for functions called before declared inline
> Today I ran into a problem building today's GCC trunk with an older > GCC 4.3. There is a warning in libcpp/macro.c about > tokens_buff_remove_last_token declared inline after being called. A previous instance: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01426.html -- Eric Botcazou
Re: Warning for functions called before declared inline
On Thu, Dec 1, 2011 at 7:42 PM, Joseph S. Myers wrote: > On Thu, 1 Dec 2011, Steven Bosscher wrote: > >> Is it valid in dialects older than C99 to declare a function static >> inline after calling it? Should the warnings be brought back in the >> compiler? > > Older dialects didn't have inline. Not even gnu89? >> One reason to bring the warnings back could be that there is now no >> way for anyone bootstrapping GCC to detect this warning. If it is >> still a goal that recently modern GCC's should be able to build the >> latest GCC, then it would be good if the latest GCC warns about the >> same things in a given C dialect as older GCC versions do. > > Building with older GCC should not use -Werror; only later bootstrap > stages, or --enable-werror-always, should do so, and > --enable-werror-always is meant to be used for building a cross-compiler > using the same version of GCC. Hm, I didn't do anything special. Just configure --target=arm-eabi, then make. Perhaps there is an error in configure.ac. Ciao! Steven
Re: Warning for functions called before declared inline
On Thu, 1 Dec 2011, Steven Bosscher wrote: > Is it valid in dialects older than C99 to declare a function static > inline after calling it? Should the warnings be brought back in the > compiler? Older dialects didn't have inline. > One reason to bring the warnings back could be that there is now no > way for anyone bootstrapping GCC to detect this warning. If it is > still a goal that recently modern GCC's should be able to build the > latest GCC, then it would be good if the latest GCC warns about the > same things in a given C dialect as older GCC versions do. Building with older GCC should not use -Werror; only later bootstrap stages, or --enable-werror-always, should do so, and --enable-werror-always is meant to be used for building a cross-compiler using the same version of GCC. In general GCC is only clean for warnings with the same version of GCC; building with 4.3 will give plenty of warnings relating to changes in GCC's internal diagnostic format as well. -- Joseph S. Myers jos...@codesourcery.com
Re: C++ memory model... What to do with libatomic
On 11/30/2011 10:07 AM, Andrew MacLeod wrote: > PS. Reflecting upon it, I wonder if it could be a part of the gcc > libraries like libgomp or libitm are. During configuration we could > check to see if there is an existing libatomic in the system, and if > there is NOT, enable building libatomic... Maybe that would be > best? then it would "just work" for all gcc users. Or at least the > vast majority. I think this is almost certainly best. For GNU/Linux this might as well be forever; after all, to whom are we going to defer this work? For other operating systems, at least for the next few years until there is some hope of a standardized external libatomic to which we can defer. > A bit late in the game for this release, so an easily downloadable > source file would probably have to do this time around for anyone > that happens to need it for non-lockfree atomics... Nah. No later, really, than libitm. Getting it checked in is the only way its going to get tested anyway. r~
Warning for functions called before declared inline
Hello,
Today I ran into a problem building today's GCC trunk with an older
GCC 4.3. There is a warning in libcpp/macro.c about
tokens_buff_remove_last_token declared inline after being called.
(This is apparently valid C99 but is it also valid C89?) After some
digging and diffing, it turns out that the warning exists in GCC 4.3
but not in newer GCC versions. Anyone trying to build a recent trunk
(r180082 or newer) with GCC 4.3 or earlier should run into this
problem.
Simple test case:
typedef struct _cpp_buff _cpp_buff;
struct _cpp_buff { struct _cpp_buff *next; unsigned char *base, *cur, *limit; };
static void tokens_buff_remove_last_token (_cpp_buff *);
void foo (_cpp_buff *buff) { tokens_buff_remove_last_token (buff); }
static inline void tokens_buff_remove_last_token (_cpp_buff
*tokens_buff) { return; }
t.c:3: warning: `tokens_buff_remove_last_token' declared inline after
being called
t.c:3: warning: previous declaration of `tokens_buff_remove_last_token' was here
The warning is easy to fix, but the underlying problem requires a
closer look also.
This warning and another one for a similar issue were removed with the
patch from Honza to remove all non-"unit-at-a-time" code in r138140:
http://gcc.gnu.org/viewcvs?view=revision&revision=138140
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01756.html
This hunk removed the warning from the compiler:
Index: c-decl.c
===
*** c-decl.c(revision 138005)
--- c-decl.c(working copy)
*** diagnose_mismatched_decls (tree newdecl,
*** 1515,1544
"noinline follows inline declaration ", newdecl);
warned = true;
}
-
- /* Inline declaration after use or definition.
-??? Should we still warn about this now we have unit-at-a-time
-mode and can get it right?
-Definitely don't complain if the decls are in different translation
-units.
-C99 permits this, so don't warn in that case. (The function
-may not be inlined everywhere in function-at-a-time mode, but
-we still shouldn't warn.) */
- if (DECL_DECLARED_INLINE_P (newdecl) &&
!DECL_DECLARED_INLINE_P (olddecl)
- && same_translation_unit_p (olddecl, newdecl)
- && flag_gnu89_inline)
- {
- if (TREE_USED (olddecl))
- {
- warning (0, "%q+D declared inline after being called", olddecl);
- warned = true;
- }
- else if (DECL_INITIAL (olddecl))
- {
- warning (0, "%q+D declared inline after its definition", olddecl);
- warned = true;
- }
- }
}
else /* PARM_DECL, VAR_DECL */
{
--- 1515,1520
Is it valid in dialects older than C99 to declare a function static
inline after calling it? Should the warnings be brought back in the
compiler?
One reason to bring the warnings back could be that there is now no
way for anyone bootstrapping GCC to detect this warning. If it is
still a goal that recently modern GCC's should be able to build the
latest GCC, then it would be good if the latest GCC warns about the
same things in a given C dialect as older GCC versions do.
What to do?
Ciao!
Steven
Re: At which pass thing goes wrong for PR43491?
On Thu, Dec 1, 2011 at 11:12 AM, Amker.Cheng wrote: > On Sat, Nov 26, 2011 at 3:41 PM, Amker.Cheng wrote: >> Hi, >> I looked into PR43491 a while and found in this case the gimple >> generated before pre >> is like: >> >> reg.0_12 = reg >> ... >> c() >> reg.0_1 = reg >> D.xxx = MEM[reg.0_1 + 8B] >> >> The pre pass transforms it into: >> >> reg.0_12 = reg >> ... >> c() >> reg.0_1 = reg.0_12 >> D.xxx = MEM[reg.0_1 + 8B] >> >> From now on, following passes(like copy_prop) can not transform it back and >> resulting in an additional mov instruction as the bug reported. >> >> The flow is like: >> 1, when rewriting gimple into ssa, reg is treated as a memory use; >> 2, seems pre noticed that reg is const and replace reg with reg.0_12, >> by this pre thinks it has eliminated an additional memory load operation; >> 3, following passes do not transform it back either because reg is treated >> as mem use or the const attribute is ignored. >> >> I think pre does the right thing given the information it knows, so wondering >> at which pass thing starts going wrong and how could this issue be handled? >> > > Should PRE be changed to global register variable aware, thus it does not > do the mentioned unnecessary elimination? Well, it's not that easy if you still want to properly do redundant expression removal on global registers. Richard. > > -- > Best Regards.
Re: At which pass thing goes wrong for PR43491?
On Sat, Nov 26, 2011 at 3:41 PM, Amker.Cheng wrote: > Hi, > I looked into PR43491 a while and found in this case the gimple > generated before pre > is like: > > reg.0_12 = reg > ... > c() > reg.0_1 = reg > D.xxx = MEM[reg.0_1 + 8B] > > The pre pass transforms it into: > > reg.0_12 = reg > ... > c() > reg.0_1 = reg.0_12 > D.xxx = MEM[reg.0_1 + 8B] > > From now on, following passes(like copy_prop) can not transform it back and > resulting in an additional mov instruction as the bug reported. > > The flow is like: > 1, when rewriting gimple into ssa, reg is treated as a memory use; > 2, seems pre noticed that reg is const and replace reg with reg.0_12, > by this pre thinks it has eliminated an additional memory load operation; > 3, following passes do not transform it back either because reg is treated > as mem use or the const attribute is ignored. > > I think pre does the right thing given the information it knows, so wondering > at which pass thing starts going wrong and how could this issue be handled? > Should PRE be changed to global register variable aware, thus it does not do the mentioned unnecessary elimination? -- Best Regards.
