Hi, all
I am studying on what kind of information a compiler can pass to a
binary translator (QEMU, for example) so that the binary translator
can do much aggressive optimization. Previous discussion [1] gave an
example on what I want to do. And in the end of the discussion, it
showed that GCC i
> But where do you want that information to be at runtime?
>
> 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_epi
陳韋任 writes:
> I am looking into config/arch which defines TARGET_MACHINE_DEPENDENT_REORG
> and
> trying to figure out what kind of operations might change the CFG.
When I want to look for a backend that does something crazy, I usually
start with sh. And sure enough, sh_reorg calls split_bran
> >> Different targets use the machine reorg pass for all sorts of different
> >> things. Most of the code in reorg.c is actually not the machine reorg
> >> pass, it is the delay slots pass (pass_delay_slots). The machine reorg
> >> pass (pass_machine_reorg) simply calls targetm.machine_dependent
陳韋任 writes:
>> Different targets use the machine reorg pass for all sorts of different
>> things. Most of the code in reorg.c is actually not the machine reorg
>> pass, it is the delay slots pass (pass_delay_slots). The machine reorg
>> pass (pass_machine_reorg) simply calls targetm.machine_dep
> Sure: the document source is gcc/doc/cfg.texi. Thanks.
Already sent to gcc-patches. :-)
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01003.html
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-37
> Different targets use the machine reorg pass for all sorts of different
> things. Most of the code in reorg.c is actually not the machine reorg
> pass, it is the delay slots pass (pass_delay_slots). The machine reorg
> pass (pass_machine_reorg) simply calls targetm.machine_dependent_reorg,
> wh
陳韋任 writes:
>> The machine reorg pass in particular can change anything, and may change
>> the CFG. The delay slots pass may also change the CFG. It depends on
>> your particular target.
>
> From the comments and source code in gcc/reorg.c, I guess both machine
> reorg pass and delay slots pa
陳韋任 writes:
>> > At the end of the link belows,
>> >
>> > http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG
>> >
>> > It says,
>> >
>> > "Note that at present, the representation of control flow in the tree
>> > representation is discarded before expanding t
> The machine reorg pass in particular can change anything, and may change
> the CFG. The delay slots pass may also change the CFG. It depends on
> your particular target.
From the comments and source code in gcc/reorg.c, I guess both machine
reorg pass and delay slots pass are for delayed-bra
> > At the end of the link belows,
> >
> > http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG
> >
> > It says,
> >
> > "Note that at present, the representation of control flow in the tree
> > representation is discarded before expanding to RTL. Long term the C
陳韋任 writes:
>> That documentation is out of date. The CFG is now retained through most
>> of the RTL passes.
>
> You said "through most of the RTLpasses". And I found the CFG
> is freed before other passes in gcc/passes.c.
>
> NEXT_PASS (pass_free_cfg);
> NEXT_PASS (pass_machine_reorg)
Hi, Ian
> That documentation is out of date. The CFG is now retained through most
> of the RTL passes.
You said "through most of the RTLpasses". And I found the CFG
is freed before other passes in gcc/passes.c.
NEXT_PASS (pass_free_cfg);
NEXT_PASS (pass_machine_reorg);
NEXT_PASS (
陳韋任 writes:
>> Can I dump other information such as CFG in a similar way as register
>> usage does?
>
> At the end of the link belows,
>
> http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG
>
> It says,
>
> "Note that at present, the representation of contr
Hi, all
> Can I dump other information such as CFG in a similar way as register
> usage does?
At the end of the link belows,
http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG
It says,
"Note that at present, the representation of control flow in the tree
Fwd to the list.
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
--- Begin Message ---
I think you can try to modify the assembler to extend the assemble
syntax to encoding the info (such as add some extensi
Hi, all
Currently, I am trying to dump basic block live-ins/outs information
as my first step. In order to let a binary translator (i.e. QEMU) to
use such information, I need to associate each basic block with its
corresponding binary address.
I tried to use `-Wa,--keep-locals` option, but I
陳韋任 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
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
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,
陳韋任 writes:
> Assume I want basic block register usage information, and
> I further assume that native machine has a register set
> {R0, R1, R2, R3}. The source code might be compiled into
> two basic blocks. What I want is something like,
>
>BB1 (0x100 - 0x120)
>In 0100
>
Hi, Ian
I will try my best to explain what I want. :-)
Assume I want basic block register usage information, and
I further assume that native machine has a register set
{R0, R1, R2, R3}. The source code might be compiled into
two basic blocks. What I want is something like,
BB1 (0x100
陳韋任 writes:
> I found a gcc plugin called gcc-vcg-plugin
> (http://code.google.com/p/gcc-vcg-plugin/). I am not sure
> if this can be a start point.
>
> Any comments? Thanks.
I honestly don't know whether you can use that as a starting point,
because I don't know what you actually want to do
Hi, Ian
I found a gcc plugin called gcc-vcg-plugin
(http://code.google.com/p/gcc-vcg-plugin/). I am not sure
if this can be a start point.
Any comments? Thanks.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Te
Hi, all
I am wondering if there is any possibility that gcc can
generate annotations like control flow, or register usage
into the executable. The idea comes from the paper below,
Techniques to improve dynamic binary optimization
http://www-users.cs.umn.edu/~adas/adas-thesis-embed.pdf
The
25 matches
Mail list logo
