On Tue, 22 Nov 2005, Joseph S. Myers wrote:
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?
Yes, exactly. LLVM isn't all the way there yet, but it is making
progress. For example, we want to be able to say that the overflow
behavior of an integer add is one of: undefined,
signed/unsigned-saturating, 2s complement, or trapping on a per-instance
basis. This is needed to efficiently support languages like MSIL which
have trapping and non-trapping versions of arithmetic operations among
other things.
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.
Precisely.
(*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.)
Yup, the idea is to be able to support things like the C99 pragmas for FP
control, capture the semantics of FORTRAN parentheses, etc.
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.
Absolutely. LLVM does not currently provide this natively (it tries to
integrate as seamlessly as possible, including emulating the
expected behavior in the case where prototypes don't match, etc), but it
could be extended to do this if desired.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
