llvm dev - May 2019 - How to get CLang array alloca alignments to be smaller than 16 bytes?

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>
wrote:
> 
> On Sun, 5 May 2019 at 21:49, Joan Lluch <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190505/ff5fb498/attachment.html>

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> 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>
wrote:
>
> On Sun, 5 May 2019 at 21:49, Joan Lluch <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
> 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/20190505/bfcae781/attachment-0001.html>

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>