This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LLVM/GCC Integration Proposal


On Sat, 19 Nov 2005, Chris Lattner wrote:

> This is a direct result of the representation that you are proposing to use
> for IPA.  LLVM is *always* capable of merging two translation units correctly,

So compilation options which change the semantics of GIMPLE are translated 
into local flags on the relevant code in LLVM (or failing that combined to 
the most conservative settings, but not all such options have such 
settings) - or it will be extended so that they are?  Examples: -ftrapv 
-fwrapv -fno-math-errno -funsafe-math-optimizations 
-funsafe-loop-optimizations -ffinite-math-only -fno-trapping-math 
-frounding-math -ffloat-store -fsignaling-nans -fcx-limited-range.  That 
sounds good if so; good implementation of C99 pragmas requires some of 
these settings to be appliable locally to particular blocks of code, which 
we don't currently have the infrastructure to do.  (*Any* combining of 
separately compiled translation units needs some way to deal with this 
problem - semantics depending on global variables - as well as for the 
places where the semantics of GIMPLE depend on langhooks which are 
different for different languages.  Of course all globals and hooks should 
be audited for such implicit effect on semantics.)

That said, while in cases of such different options combining is 
desirable, there are cases where refusing to combine is a feature not a 
bug - if the user program can be detected to have incompatible translation 
units (e.g. where the same named function takes different types of 
arguments) then telling the user is useful, and if the program has some of 
the stranger combinations of types that may or may not be valid in C 
(DR#314 and subsequent discussion in Mt Tremblant minutes) then diagnosing 
this is also useful.  Of course it's not the optimizer's job to diagnose 
such things, but infrastructure to diagnose them (possibly quite separate 
from that for optimization) can be useful.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]