llvm dev - Aug 2015 - [LLVMdev] Ideas for making llvm-config --cxxflags more useful

[Ooops, sent to the old list address by mistake]

On 30 Jul 2015, at 21:04, tom at stellard.net wrote:
> 
> For flags like -fno-rtti (are there others?) that are required in some
cases
> (I think -fno-rtti is required only if you sub-class LLVM objects), I would
propose
> adding a separate flag like --uses-rtti.  This would give users more
fine-grained
> control over which flags they use, and also would let them choose the
correct
> flag since, for example, -fno-rtti is not understood by MSVC.
There appears to be a regression in LLVM 3.7, which means that you must compile
with -fno-rtti if you include llvm’s Instructions.h.  The issue is that a few of
the classes (ICmpInst, GetElementPtrInst and PHINode) are now defined entirely
in the header, so every compilation unit that includes the header will emit
them.  These classes all inherit from Instruction (indirectly via CmpInst in the
case of ICmpInst) and so fail to link if compiled with -fno-rtti, because they
can’t find the vtable for ICmpInst.

It would be nice to see this fixed before 3.7 is pushed out, but if it isn’t
then we will still need to keep it in mind for llvm-config.

David

On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> [Ooops, sent to the old list address by mistake]
>
> On 30 Jul 2015, at 21:04, tom at stellard.net wrote:
>>
>> For flags like -fno-rtti (are there others?) that are required in some
cases
>> (I think -fno-rtti is required only if you sub-class LLVM objects), I
would propose
>> adding a separate flag like --uses-rtti.  This would give users more
fine-grained
>> control over which flags they use, and also would let them choose the
correct
>> flag since, for example, -fno-rtti is not understood by MSVC.
>
> There appears to be a regression in LLVM 3.7, which means that you must
compile with -fno-rtti if you include llvm’s Instructions.h.  The issue is that
a few of the classes (ICmpInst, GetElementPtrInst and PHINode) are now defined
entirely in the header, so every compilation unit that includes the header will
emit them.  These classes all inherit from Instruction (indirectly via CmpInst
in the case of ICmpInst) and so fail to link if compiled with -fno-rtti, because
they can’t find the vtable for ICmpInst.
I looked at the file, and this didn't seem true (e.g.
GetElementPtrInst::init is still out-of-line). But then I realized you
mean virtual functions, so these classes no longer have a key
function.

This is probably Pete's r240588. I suppose we could add key functions
to these classes (even if they're not used for anything). I'm not sure
how we'd prevent this from regressing though :-/

 - Hans

On Fri, Aug 7, 2015 at 10:22 AM, Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > [Ooops, sent to the old list address by mistake]
> >
> > On 30 Jul 2015, at 21:04, tom at stellard.net wrote:
> >>
> >> For flags like -fno-rtti (are there others?) that are required in
some
> cases
> >> (I think -fno-rtti is required only if you sub-class LLVM
objects), I
> would propose
> >> adding a separate flag like --uses-rtti.  This would give users
more
> fine-grained
> >> control over which flags they use, and also would let them choose
the
> correct
> >> flag since, for example, -fno-rtti is not understood by MSVC.
> >
> > There appears to be a regression in LLVM 3.7, which means that you
must
> compile with -fno-rtti if you include llvm’s Instructions.h.  The issue is
> that a few of the classes (ICmpInst, GetElementPtrInst and PHINode) are now
> defined entirely in the header, so every compilation unit that includes the
> header will emit them.  These classes all inherit from Instruction
> (indirectly via CmpInst in the case of ICmpInst) and so fail to link if
> compiled with -fno-rtti, because they can’t find the vtable for ICmpInst.
>
> I looked at the file, and this didn't seem true (e.g.
> GetElementPtrInst::init is still out-of-line). But then I realized you
> mean virtual functions, so these classes no longer have a key
> function.
>
> This is probably Pete's r240588. I suppose we could add key functions
> to these classes (even if they're not used for anything). I'm not
sure
> how we'd prevent this from regressing though :-/
>
In theory the LLVM style guide mandates key functions for all dynamic
classes (under the claim of build performance - avoiding duplicate vtable
emission, etc). We've never strongly enforced it though - if we really
wanted to, we could do so as Clang has a warning that triggers whenever a
vtable is emitted weakly (which is what happens when there isn't a key
function).

- David

>
>  - Hans
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150807/39d33b4c/attachment.html>