[llvm-dev] How to get CLang array alloca alignments to be smaller than 16 bytes?
Joan Lluch via llvm-dev
llvm-dev at lists.llvm.org
Mon May 6 13:43:52 PDT 2019
Hi Don,
Thank you for your reply and pointers. I suppose everybody choses their tools based on previous experience or skills so that’s why I chose Xcode. I do not think that incremental builds are that slow, they take just a few seconds on my late 2009 iMac. Of course the full CLANG+LLVM build from ‘clean’ takes a while, 15 minutes on my old mac, but there’s no need to do so. There are two particular features that I love from Xcode. The totally integrated debugger and profiler tools, and the code sense features with live error checking (compiler errors as you type) that will save you a lot of failed compilation iterations. I do not know how common these features are if other IDEs, so I may well have a look at Ninja, but as said I’m used to Xcode which I find easy to use.
So back on topic, I made changes to create a CLang frontent configuration for my architecture. As a starting point, I based it on (I actually copied) the MSP430 implementation, because it’s the only genuinely 16 bit architecture available, and so far it’s working as I expect.
The underlying problem with LLVM is the lack of a set of documentation that would goes beyond just scratching the surface. Unfortunately this means that there’s a lot of trial an error and debugging through the existing code until you get to ever figure out how to implement things. It’s a pity that the usual scenario for everything open source, is that everybody wants documentation but nobody is interested in creating it.
John
> On 5 May 2019, at 23:56, Don Hinton <hintonda at gmail.com> wrote:
>
> Hi Joan:
>
> I'm sure there are people that use the XCode generator, but I develop on a Mac and don't use it -- well, I did try it once and was underwhelmed by what it produced and gave up on it. So, I just use Ninja, which is fast and works great. Also, since it seems like a lot of people use it, it's well tested, and you don't have the issues you're having with XCode. Plus it works the some on the other platforms I use, e.g., Linux.
>
> I do use the XCode debugger from time to time -- just setup an external project and it figures everything out.
>
> hth...
> don
>
> On Sun, May 5, 2019 at 2:24 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> To be honest, I don’t either know what really happens under the hood when CMake creates the xCode project for CLang+LLVM. But there’s something really explicit going on there, because the project as it’s shown in xCode does not have the same file grouping structure than the actual physical folders. Not only the project file grouping doesn't match the physical folder locations, but the group naming is different and generally more convenient and organised than the actual folder structure. What does all that, I have no idea, but cmake creates it all by just selecting xCode as the cmake “generator”.
>
> John
>
>> On 5 May 2019, at 22:58, Tim Northover <t.p.northover at gmail.com <mailto:t.p.northover at gmail.com>> wrote:
>>
>> On Sun, 5 May 2019 at 21:49, Joan Lluch <joan.lluch at icloud.com <mailto:joan.lluch at icloud.com>> wrote:
>>> However, I now have found that for some reason the .h files in the lib/Basic/Targets directory were not included as part of the Xcode project.
>>
>> Ah. At least we now have a common view on the source, and hopefully
>> you can see what needs doing (even if Xcode won't reflect reality
>> properly for whatever reason).
>>
>>> I assume this is a bug on one of the cmake install files.
>>
>> As far as I'm aware LLVM has little to no Xcode magic in its CMake
>> files. So the bug would be in either CMake (supplying inadequate
>> dependencies?) or Xcode (misinterpreting CMake output?).
>>
>> I'm afraid I don't really know enough about either to say which is
>> responsible. It could even be LLVM, though from what I *have* seen of
>> CMake, I'd be surprised if we needed to declare headers.
>>
>> Cheers.
>>
>> Tim.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://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/20190506/e0015043/attachment.html>
More information about the llvm-dev
mailing list