How to get function argument points-to information.
For some analysis I am doing, I need to determine if a particular SSA_NAME_VAR node is pointed-to by a function argument. I am iterating across the function's arguments via DECL_ARGUMENTS(), but each argument is just a DECL node, and contains no associated points-to data, as far as I can tell. I assume there is a better/different way of determining if an argument points to my node? Thanks for any insight. -Matt
Re: Generate annotations for a binary translator
Hi, > The hard part is not getting the information at compile time. The > information is readily available after register allocation. Heck, you > can see right in the dump files; e.g., use -da when you compile and look > at the pro_and_epilogue dump file. I am glad to hear that news. Thanks, Ian. > The hard part is getting that information to be available at runtime. The easiest way is saving that information on the disk. Or I can use `objcopy` to insert the information to the executable. The binary translator can read that information at runtime. I guess what "the hard part" you mean is how to insert that information into executable directly without using something like `objcopy`. Is that right? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: Generate annotations for a binary translator
Hi, > The hard part is not getting the information at compile time. The > information is readily available after register allocation. Heck, you > can see right in the dump files; e.g., use -da when you compile and look > at the pro_and_epilogue dump file. Can I dump other information such as CFG in a similar way as register usage does? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: How to get function argument points-to information.
On Tue, May 17, 2011 at 10:10 AM, Matt Davis wrote: > For some analysis I am doing, I need to determine if a particular SSA_NAME_VAR > node is pointed-to by a function argument. I am iterating across the > function's > arguments via DECL_ARGUMENTS(), but each argument is just a DECL node, and > contains no associated points-to data, as far as I can tell. I assume there > is > a better/different way of determining if an argument points to my node? > > Thanks for any insight. Look at the decls default SSA definition (gimple_default_def (cfun, decl)). Richard. > -Matt >
Re: Generate annotations for a binary translator
陳韋任 writes: >> The hard part is getting that information to be available at runtime. > > The easiest way is saving that information on the disk. Or I can use > `objcopy` to insert the information to the executable. The binary > translator can read that information at runtime. > > I guess what "the hard part" you mean is how to insert that > information into executable directly without using something like > `objcopy`. Is that right? You need to define a format, you need to have code which can read it, you need to be able to do something useful with it, etc. I guess from my perspective that seems like the hard part, since the information is readily available in the compiler. > Can I dump other information such as CFG in a similar way as register > usage does? Sure, you can do whatever you like. Ian
Problem with reload generating direct memory accesses also GO_IF_LEGITIMATE_ADDRESS does not permit this
Hello,
I'm currently writing a gcc backend for a microcontroller architecture which
can only handle indirect memory accesses.
In normal cases all works fine, but there is a special case where the reload
pass (<- not sure) produces a direct memory access in -O2 optimization mode
which causes the postreload pass to abort.
The relevant c-code uses a constant memory address:
#define IO_BASE (0x34000)
#define UART2OFF(0x08)
#define UART2BASE ((void *)(IO_BASE+(UART2OFF*2)))
u = (struct uart *)UART2BASE;
So basically u has the constant address 0x34010 which is known at compile time.
The instruction where the error occurs is the following:
u->tx_data = tx;
In the source.c.128r.expand dump file this line looks like this:
(insn 40 39 41 5 ../uart2sim/uart2i_3.c:272 (set (reg/f:HI 46)
(symbol_ref:HI ("tx") [flags 0x2] )) -1 (nil))
(insn 41 40 42 5 ../uart2sim/uart2i_3.c:272 (set (reg:HI 28 [ tx.44 ])
(zero_extend:HI (mem/c/i:QI (reg/f:HI 46) [0 tx+0 S1 A9]))) -1 (nil))
(insn 42 41 43 5 ../uart2sim/uart2i_3.c:272 (set (reg:HI 27 [ D.1392 ])
(reg:HI 28 [ tx.44 ])) -1 (nil))
(insn 43 42 44 5 ../uart2sim/uart2i_3.c:272 (set (reg/f:HI 47)
(const_int -49136 [0x4010])) -1 (nil))
(insn 44 43 45 5 ../uart2sim/uart2i_3.c:272 (set (mem/s:HI (plus:HI (reg/f:HI
47)
(const_int 4 [0x4])) [2 .tx_data+0 S2 A18])
(reg:HI 27 [ D.1392 ])) -1 (nil))
So basically its like it should be. An indirect store operation using pseudo
register 47 as base register. The fact that the constant 0x34010 is negative is
due to the fact that our pmode is only 18 bit wide. It shouldn't be a problem
if the constant gets loaded into a register.
The above insns change a bit during the following passes. In the
source.c.168r.asmcons dump file it basically looks like this:
(insn 171 36 43 2 ../uart2sim/uart2i_3.c:272 (set (reg/f:HI 104)
(reg/f:HI 85)) 2 {movhi} (expr_list:REG_EQUAL (symbol_ref:HI ("tx")
[flags 0x2] )
(nil)))
(insn 43 171 49 2 ../uart2sim/uart2i_3.c:272 (set (reg/f:HI 105)
(reg/f:HI 35)) 2 {movhi} (expr_list:REG_DEAD (reg/f:HI 35)
(expr_list:REG_EQUAL (const_int -49136 [0x4010])
(nil
(insn 41 39 44 4 ../uart2sim/uart2i_3.c:272 (set (reg:HI 28 [ tx.44 ])
(zero_extend:HI (mem/c/i:QI (reg/f:HI 85) [0 tx+0 S1 A9]))) 26
{zero_extendqihi2} (expr_list:REG_EQUAL (zero_extend:HI (mem/c/i:QI
(symbol_ref:HI ("tx") [flags 0x2] ) [0 tx+0 S1 A9]))
(nil)))
(insn 44 41 45 4 ../uart2sim/uart2i_3.c:272 (set (mem/s:HI (plus:HI (reg/f:HI
105)
(const_int 4 [0x4])) [2 .tx_data+0 S2 A18])
(reg:HI 28 [ tx.44 ])) 2 {movhi} (nil))
So the memory instruction is still indirect. But after the ira/reload pass the
following is found in the source.c.172r.ira dump file:
(insn 41 39 44 4 ../uart2sim/uart2i_3.c:272 (set (reg:HI 7 r7 [orig:28 tx.44 ]
[28])
(zero_extend:HI (mem/c/i:QI (reg/f:HI 9 r9 [85]) [0 tx+0 S1 A9]))) 26
{zero_extendqihi2} (expr_list:REG_EQUAL (zero_extend:HI (mem/c/i:QI
(symbol_ref:HI ("tx") [flags 0x2] ) [0 tx+0 S1 A9]))
(nil)))
(insn 44 41 45 4 ../uart2sim/uart2i_3.c:272 (set (mem/s:HI (plus:HI (const_int
-49136 [0x4010])
(const_int 4 [0x4])) [2 .tx_data+0 S2 A18])
(reg:HI 7 r7 [orig:28 tx.44 ] [28])) 2 {movhi} (nil))
So NOW it is a direct store operation. And the compiler crashes with the
following error message:
../uart2sim/uart2i_3.c: In Funktion »main«:
../uart2sim/uart2i_3.c:307: Fehler: Befehl erfüllt nicht seine Bedingungen:
(insn 44 41 45 4 ../uart2sim/uart2i_3.c:272 (set (mem/s:HI (plus:HI (const_int
-49136 [0x4010])
(const_int 4 [0x4])) [2 .tx_data+0 S2 A18])
(reg:HI 7 r7 [orig:28 tx.44 ] [28])) 2 {movhi} (nil))
../uart2sim/uart2i_3.c:307: interner Compiler-Fehler: in
reload_cse_simplify_operands, bei postreload.c:396
Its German output. In English it sais that the instruction doesn't match its
constraints which are tested in line 396 in postreload.c which looks like this:
/* Figure out which alternative currently matches. */
if (! constrain_operands (1))
fatal_insn_not_found (insn);
Obviously this line asks the GO_IF_LEGITIMATE_ADDRESS macro. If I allow direct
addresses there, the postreload pass doesn't crash.
The GO_IF_LEGITIMATE_ADDRESS helper function looks like this:
int valid = 0;
switch (GET_CODE (x))
{
case REG:
valid = REG_OK_FOR_BASE_P (x);
break;
case PLUS:
{
rtx base = XEXP (x, 0);
rtx offset = XEXP (x, 1);
valid = (REG == GET_CODE (base) &&
REGNO_OK_FOR_BASE_P (base) &&
CONST_INT == GET_CODE (offset) &&
GET_CODE(offset) != SYMBOL_REF &&
x_const_ok_for_base (m
Re: IRA observation/question
On 05/16/2011 05:00 PM, Pat Haugen wrote:
I'm seeing some odd behavior in ira for PowerPC, starting with the big
ira merge best I can tell (r171649).
void foo(float *f1, float*f2) {
*f1 = *f2;
}
If I compile with gcc -S -m64 -O3 -mcpu=power7 and look at the ira
dump, I see that the pseudo used to copy the data, r120, is spilled.
Reload comes along and fixes up this simple example so we end up with
just a load/store for the copy, but spilling when we have plenty of
available registers is obviously wrong.
Portion of the ira dump:
Pass 0 for finding pseudo/allocno costs
r120 costs: BASE_REGS:0 GENERAL_REGS:0 FLOAT_REGS:0 VSX_REGS:200
NON_SPECIAL_REGS:16000 LINK_REGS:4000 CTR_REGS:4000
LINK_OR_CTR_REGS:4000 SPECIAL_REGS:4000 SPEC_OR_GEN_REGS:4000
NON_FLOAT_REGS:200 ALL_REGS:200 MEM:8000
Pass 1 for finding pseudo/allocno costs
r122: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r121: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r120: preferred SPEC_OR_GEN_REGS, alternative NO_REGS, allocno
SPEC_OR_GEN_REGS
r119: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r118: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r117: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r116: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r115: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r114: preferred ALL_REGS, alternative NO_REGS, allocno ALL_REGS
r120 costs: VSX_REGS:200 NON_SPECIAL_REGS:16000 LINK_REGS:4000
CTR_REGS:4000 LINK_OR_CTR_REGS:4000 SPECIAL_REGS:4000
SPEC_OR_GEN_REGS:4000 NON_FLOAT_REGS:200 ALL_REGS:200 MEM:8000
Building IRA IR
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
init_insns for 120: (insn_list:REG_DEP_TRUE 8 (nil))
Pass 1 for finding pseudo/allocno costs
r120: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS
a0 (r120,l0) best NO_REGS, allocno NO_REGS
a0(r120,l0) costs: FLOAT_REGS:16000,16000 VSX_REGS:200,200
NON_SPECIAL_REGS:16000,16000 SPEC_OR_GEN_REGS:4000,4000
NON_FLOAT_REGS:200,200 ALL_REGS:200,200 MEM:0,0
...
Allocnos coloring:
Loop 0 (parent -1, header bb0, depth 0)
bbs: 2
all: 0r120
modified regnos: 120
border:
Pressure: NON_FLOAT_REGS=2
Hard reg set forest:
0:( 0 3-12 14-63 65 66 68-72 74 75 77-108)@0
Spill a0(r120,l0)
Disposition:
0:r120 l0 mem
Things start to go wrong during the first pass of
find_costs_and_classes, while walking the list of cost_classes to find
the best. If two classes have the same cost (such as GENERAL_REGS and
FLOAT_REGS in this example) the following portion of code grabs a
union of them.
else if (i_costs[k] == best_cost)
best = ira_reg_class_subunion[best][rclass];
In this case that class is NON_SPECIAL_REGS, which has a cost greater
than both due to the fact that move cost for GPR<->FPR needs to go
through memory, and may_move_[in|out]_cost use maximal cost when
computing cost such as NON_SPECIAL<->[GENERAL|FLOAT]. Picking
NON_SPECIAL for the best class during the first iteration then affects
subsequent iterations until it's decided that memory is best.
The following change fixes the problem by not updating the best_cost
if the union has a greater cost. Is this the correct approach or is
there more to it than this?
Thanks for pointing this out, Pat. Your patch could fix this particular
problem but using GENERAL_REGS only is wrong. The final allocno class
should be NON_SPECIAL_REGS. I will search for a better solution.
Unfortunately, such changes in the code should be benchmarked on a few
major targets. So it will take some time (a weak or two) to fix the
problem.
===
--- gcc/ira-costs.c (revision 173392)
+++ gcc/ira-costs.c (working copy)
@@ -1697,7 +1697,14 @@ find_costs_and_classes (FILE *dump_file)
best = (enum reg_class) rclass;
}
else if (i_costs[k] == best_cost)
- best = ira_reg_class_subunion[best][rclass];
+ {
+ enum reg_class temp_class;
+ temp_class = ira_reg_class_subunion[best][rclass];
+ if (cost_classes_ptr->index[temp_class] != -1
+ && i_costs[cost_classes_ptr->index[temp_class]]
+ <= best_cost)
+ best = temp_class;
+ }
if (pass == flag_expensive_optimizations
&& i_costs[k] < i_mem_cost
&& (reg_class_size[reg_class_subunion[alt_class][rclass]]
One thing I did notice with this change is that we'll now pick
GENERAL_REGS as best on the first pass, which then causes FLOAT_REGS
to be expensive on subsequent passes. Seems like for this example
where GENERAL/FLOAT are equally best, one would be the preferred class
and the other would be th
Re: Problem with reload generating direct memory accesses also GO_IF_LEGITIMATE_ADDRESS does not permit this
Camo Johnson writes:
> So NOW it is a direct store operation. And the compiler crashes with the
> following error message:
>
> ../uart2sim/uart2i_3.c: In Funktion »main«:
> ../uart2sim/uart2i_3.c:307: Fehler: Befehl erfüllt nicht seine Bedingungen:
> (insn 44 41 45 4 ../uart2sim/uart2i_3.c:272 (set (mem/s:HI (plus:HI
> (const_int -49136 [0x4010])
> (const_int 4 [0x4])) [2 .tx_data+0 S2 A18])
> (reg:HI 7 r7 [orig:28 tx.44 ] [28])) 2 {movhi} (nil))
> ../uart2sim/uart2i_3.c:307: interner Compiler-Fehler: in
> reload_cse_simplify_operands, bei postreload.c:396
>
> Its German output. In English it sais that the instruction doesn't match its
> constraints which are tested in line 396 in postreload.c which looks like
> this:
That's odd. Reload has decided to substitute the equivalent constant
rather than reloading it into a register. The address is (plus:HI
(const_int -49136 [0x4010]) (const_int 4 [0x4])). That is
presumably rejected by GO_IF_LEGITIMATE_ADDRESS. So I wonder how it
gets through find_reloads_address?
A quick hack might be to handle this case in LEGITIMIZE_RELOAD_ADDRESS,
but I don't see why that is needed.
Ian
Re: IRA observation/question
On 05/17/2011 11:07 AM, Vladimir Makarov wrote: Thanks for pointing this out, Pat. Your patch could fix this particular problem but using GENERAL_REGS only is wrong. The final allocno class should be NON_SPECIAL_REGS. I will search for a better solution. Unfortunately, such changes in the code should be benchmarked on a few major targets. So it will take some time (a weak or two) to fix the problem. Ok, thanks. I can lend a hand with any PowerPC testing if you want. -Pat
Problem with scanf reading long types in scientific notation
Hi, I¹m not sure if this have been dealt with or not, but I happen to be thinking about it at the moment and wanted to say something before I forget. There is as situation in which I believe an improvement is needed: Regarding all the scanf functions reading long values (sscanf,fscanf,scanf,... etc...). Currently, if a number is written in scientific notation (as will be the default case sometimes for large whole numbers that might happen to be stored in double types), scanf won¹t properly read it¹s value into a long data type. For example: if I want to read the number 15892938475 or 1.5892938475E10, 1.5892938475e10, 1.5892938475E+10, or 1.5892938475e+10 scanf(³%ld²,&longValue) ;will not read any of the later cases correctly. I imagine the same to be true for int types. Currently, what I have to do is: scanf(³%ld²,&doubleValue);longValue=doubleValue; I don¹t think I should have to write my own functions to deal with this type of standard read of plain old data, so whether it¹s a bug or just a feature request is semantics. The introduction of 64-bit systems after everything was developed for 32-bit systems has caused one set of issues. This may be related to that, but it also might be seen as a preference for large whole numbers to be more be more easily stored and converted between long and double values. Maybe the desire for this has come out of dealing with large numbers available in 64-bit systems. In my opinion, it should be changed so that scanf(³%ld²,&longValue) behaves as scanf(³%ld²,&doubleValue);longValue=doubleValue;, specifically to improve the reading of scientific numbers. It is entirely possible to have a large whole number written in scientific notation. I feel that this issue has caused bugs in many of my programs, so it should be fixed in order that others in the future can have confidence in the functionality of scanf(³%ld²,&longValue) working correctly in all cases where there is a number to be read. I propose that it be set up this way for all versions of *scanf type functions. I don¹t know if literally using the double reading algorithm and then assigning to a long or int value is the best approach or if there is a better way, but I think the functionality should be implemented in the future. Thanks, Sean McGuffee
Compiling Netbeans with GCJ?
Hi, Has anyone compiled netbeans with gcj? If so, can you please post your method? Thanks, Sean
Re: Problem with scanf reading long types in scientific notation
Sean Robert McGuffee writes: > Regarding all the scanf functions reading long values > (sscanf,fscanf,scanf,... etc...). I'm sorry, this is the wrong mailing list. gcc is just the compiler. Functions like sscanf, fscanf, scanf are part of the C library. gcc does not provide a C library. In any case the behaviour of these functions is specified by industry standards, and it is unlikely that anybody is going to change their meaning at this point. Ian
Re: Compiling Netbeans with GCJ?
Sean Robert McGuffee writes: > Has anyone compiled netbeans with gcj? > If so, can you please post your method? The mailing list gcc@gcc.gnu.org is for discussions related to the development of gcc itself. Questions like this should go on the mailing list gcc-h...@gcc.gnu.org. Or, in this case, the mailing list j...@gcc.gnu.org would also be appropriate. For more information, see http://gcc.gnu.org/lists.html . Thanks. Ian
gcc-4.4-20110517 is now available
Snapshot gcc-4.4-20110517 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110517/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 173836 You'll find: gcc-4.4-20110517.tar.bz2 Complete GCC (includes all of below) MD5=4e79d0c6fddf2b5ddb778bc6607c6b2f SHA1=85d32bec5cbd579ce10a949c22c711d1c7f18167 gcc-core-4.4-20110517.tar.bz2C front end and core compiler MD5=fe61ae67552aebe194545480322f34d0 SHA1=21783b541ab35ad9c45e7a2da2ff841e2ca8228e gcc-ada-4.4-20110517.tar.bz2 Ada front end and runtime MD5=aeea5136e20e73e52b406f3c88603175 SHA1=b1a2314f3b2ea923416d244984837e0b59592710 gcc-fortran-4.4-20110517.tar.bz2 Fortran front end and runtime MD5=3be59727434b1b5298b44ed556e53921 SHA1=53e8523084f16886c72dd7dca5da902367e10fbf gcc-g++-4.4-20110517.tar.bz2 C++ front end and runtime MD5=53cff036369abb282078a68680ef08dd SHA1=0ce154dff9214cd05d37b2add7853cc2c6b0650a gcc-go-4.4-20110517.tar.bz2 Go front end and runtime MD5=05d69eaab5d667b3398fa82423c656b9 SHA1=6bcb26a16a52accc4c66be23a9df24022c19b237 gcc-java-4.4-20110517.tar.bz2Java front end and runtime MD5=6843d4e4d437b6aa896002e01fab5a88 SHA1=dd6222907dafe2f3d6adbfb716948c569563ac13 gcc-objc-4.4-20110517.tar.bz2Objective-C front end and runtime MD5=2e55314bcb467c6768c01cd37477da64 SHA1=ea2a3b0ddcad184d78846f3cd36921a0bdf01083 gcc-testsuite-4.4-20110517.tar.bz2 The GCC testsuite MD5=8003292a2efaf625bedf7fef89bc74c0 SHA1=7ee32b06691a2cec7f9acba183d621103afb4731 Diffs from 4.4-20110510 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
