Re: Architecture-dependent optimizations

[aimen bouchhima <aimen dot bouchhima at imag dot fr>]

On Thursday 30 September 2004 19:27, Jan Hubicka wrote:
> > Hi all,
> > I'm trying to compile an application for two different target
> > architectures using gcc. My goal is to obtain 2 output binaries that have
> > the same control flow graph structure. The problem is that , some
> > architecture-dependent optimizations tend to modify the cfg structure by
> > removing/merging basic blocks etc. Trying to disable such optimizations
> > (using command line options), I found that this was rather a complex task
> > cause they are dispersed across different  optimization passes, and some
> > times mixed with other types of optimizations.
> > So my question is : Is there a simple and clean way to disable/enable
> > architecture-dependent optimizations that affect the cfg structure in
> > gcc?
>
> No, in fact almost every optimization does affect (for instance CSE
> might introduce dead instruction that might in turn result in
> ellimination of basic blocks and such).

Actually, my concern is only about those optimizations that depend on the 
target architecture AND affect the cfg . For instance, the if-conversion 
optimization may exploit some architecture-dependent features (conditional 
instructions...)  and clearly modify the underlying cfg.
The problem is that, when I tried to disable this optimization for ARM target 
(using -fno-if-conversion2 option), I noticed that not all 
conditional-instruction based optimizations were disabled (either a BUG ?? or 
probably the same optimization has been enabled from within another pass ).

I have a feeling that currently, gcc does not provide a clean separation 
between architecture-dependent and independent optimization ( may be this 
will be enabled in future using GIMBLE more efficiently)  

> What do you need this for?  Perhaps you can get bit out of current gcov
> graph dumping support...
>

I need that to run some experiments on a host target while having some 
performance estimations of another (different) target architecture ...

> Honza
>
> > Thanks in advance for any hint or comment
> >
> > Aimen