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

[Mehdi Amini]

> On Aug 3, 2015, at 10:51 AM, Chris Bieneman <beanz at apple.com> wrote:
> 
> 
>> On Aug 3, 2015, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> 
>>> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
>>> 
>>> Hey Tom,
>>> 
>>> I’m not a regular user of llvm-config, but this sounds completely right to me, and it would be a significant improvement over what we have now.
>>> 
>>> The only question I want to raise is, what about NDEBUG? There are headers that conditionalize on NDEBUG, which could lead to ABI incompatibility in the C++ API.
>> 
>> Is it something that can be fixed or would it be too complicated to handle? 
> 
> I think this would need a case-by-case determination that I haven’t done. There are quite a few occurrences of NDEBUG in headers:
> 
> > grep -r NDEBUG ./include/ | wc -l
>       77
> 
> I imagine many of these aren’t actually ABI issues, but I know that ABI issues have existed in the past.

I quickly looked at them and found these that I believe won’t trigger a linked error:

- class SCEVExpander: has a field dependent on NDEBUG: "const char *DebugType;"
- class FunctionLoweringInfo: two fields dependent on NDEBUG: SmallPtrSet<const Instruction *, 8> CatchInfoLost and CatchInfoFound
- class ScheduleDAGMI:  has a field dependent on NDEBUG: unsigned NumInstrsScheduled;
- class SchedBoundary: has a field dependent on NDEBUG: unsigned MaxObservedStall;
- class NodeMetadata: has a field dependent on NDEBUG: bool everConservativelyAllocatable;
- class ScheduleDAG: has a field dependent on NDEBUG: bool StressSched;
- class SelectionDAG: has a field dependent on NDEBUG: std::map<const SDNode *, std::string> NodeGraphAttrs;
- class AssertingVH conditionally inherit from ValueHandleBase and has a dependent field:   Value *ThePtr;
- class MCProcResourceDesc and MCSchedClassDesc have a field dependent on NDEBUG: const char *Name;


— 
Mehdi



> 
> -Chris
> 
>> It would be nice in general to be able to link a “Non assert” build of Clang with an “Assert" version of  LLVM (and vice-versa). 
>> 
>> And on the original topic: +1 for Tom proposal/goal, it makes sense to me.
>> 
>> —
>> Mehdi
>> 
>> 
>> 
>>> 
>>> Thanks for doing this,
>>> -Chris
>>> 
>>>> On Jul 30, 2015, at 1:04 PM, tom at stellard.net <mailto:tom at stellard.net> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> My understanding of llvm-config --cxxflags is that it is supposed to report
>>>> which flags are necessary to compile a program that will include LLVM's
>>>> headers and link against its libraries.  What it currently reports is
>>>> all of the flags which were used to compile LLVM.  This is not very useful,
>>>> because users are required in most cases to filter out flags they don't
>>>> want.
>>>> 
>>>> I would like to try to fix this so that it reports only the bare minimum
>>>> of required flags.  As an example here all the flags that it reports in
>>>> my autoconf build of llvm:
>>>> 
>>>> -I/usr/local/llvm/3.8/include
>>>> -D_DEBUG
>>>> -D_GNU_SOURCE
>>>> -D__STDC_CONSTANT_MACROS
>>>> -D__STDC_FORMAT_MACROS
>>>> -D__STDC_LIMIT_MACROS
>>>> -O3
>>>> -fomit-frame-pointer
>>>> -std=c++11
>>>> -fvisibility-inlines-hidden
>>>> -fno-exceptions
>>>> -fno-rtti
>>>> -fPIC
>>>> -ffunction-sections
>>>> -fdata-sections
>>>> -Wcast-qual
>>>> 
>>>> Of these flags the only ones that are really required are (c++ experts
>>>> please correct me if I'm wrong here):
>>>> 
>>>> -I/usr/local/llvm/3.8/include
>>>> -D__STDC_CONSTANT_MACROS
>>>> -D__STDC_FORMAT_MACROS
>>>> -D__STDC_LIMIT_MACROS
>>>> -std=c++11
>>>> 
>>>> Technically the -D__STDC* macros are only required if you include
>>>> Support/DataTypes.h, but I think that is hard to avoid.
>>>> 
>>>> As I understand, The rest of the flags are not required in 100% of the
>>>> use cases.
>>>> 
>>>> My proposal for fixing this is to remove everything but the 5 options listed
>>>> above.
>>>> 
>>>> 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.
>>>> 
>>>> How do people feel about this proposal?
>>>> 
>>>> Thanks,
>>>> Tom
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/6fa6fe1e/attachment.html>