Re: [llvm-commits] [llvm] r166875 - in /llvm/trunk: lib/Transforms/Scalar/LoopIdiomRecognize.cpp test/Transforms/LoopIdiom/basic.ll

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] [llvm] r166875 - in /llvm/trunk: lib/Transforms/Scalar/LoopIdiomRecognize.cpp test/Transforms/LoopIdiom/basic.ll

Benjamin Kramer

On 27.10.2012, at 18:24, Benjamin Kramer <[hidden email]> wrote:

>
> On 27.10.2012, at 18:15, Sean Silva <[hidden email]> wrote:
>
>> How does this affect freestanding implementations?
>
> This transform is disabled with -fno-builtin or -ffreestanding.

Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is too conservative. Currently -ffreestanding disables optimizing all builtin functions, just like -fno-builtin. However, the GCC manual says:

> GCC requires the freestanding environment provide memcpy,memmove, memset and memcmp.

Should we enable those functions selectively in a freestanding environment? LLVM will start optimizing calls to them, and turn loops into one of those functions if possible. I'm not sure if that behavior is acceptable with -ffreestanding.

- Ben
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] [llvm] r166875 - in /llvm/trunk: lib/Transforms/Scalar/LoopIdiomRecognize.cpp test/Transforms/LoopIdiom/basic.ll

Sean Silva
If GCC requires it, then pragmatically it's probably safe to do. Is
there any -ffreestanding code that LLVM compiles that wasn't already
being compiled with a GCC toolchain? My guess is that there isn't.

A relevant related question is what freestanding code does LLVM
currently compile in production? FreeBSD kernel and Darwin kernel come
to mind (and Linux is coming along). We also have a couple
microcontroller backends, but given the lack of maintenance (from a
quick look at git log), I'm not sure how much they are being used.
Maybe some embedded ARM and MIPS systems. AFAIK, all of these come
from a background of being built with a GCC toolchain.

-- Sean Silva

On Sat, Oct 27, 2012 at 4:32 PM, Benjamin Kramer <[hidden email]> wrote:

>
> On 27.10.2012, at 18:24, Benjamin Kramer <[hidden email]> wrote:
>
>>
>> On 27.10.2012, at 18:15, Sean Silva <[hidden email]> wrote:
>>
>>> How does this affect freestanding implementations?
>>
>> This transform is disabled with -fno-builtin or -ffreestanding.
>
> Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is too conservative. Currently -ffreestanding disables optimizing all builtin functions, just like -fno-builtin. However, the GCC manual says:
>
>> GCC requires the freestanding environment provide memcpy,memmove, memset and memcmp.
>
> Should we enable those functions selectively in a freestanding environment? LLVM will start optimizing calls to them, and turn loops into one of those functions if possible. I'm not sure if that behavior is acceptable with -ffreestanding.
>
> - Ben
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] [llvm] r166875 - in /llvm/trunk: lib/Transforms/Scalar/LoopIdiomRecognize.cpp test/Transforms/LoopIdiom/basic.ll

Chris Lattner-2
In reply to this post by Benjamin Kramer
I think it would be possible according to the gcc spec, but still a bad idea.  We regularly get bug reports from people using freestanding and getting grumpy about getting calls to memcpy for struct copies...

I think that if someone is asking for freestanding we should just forget about any performance win for stuff like this and be as least surprising as possible.

-Chris

On Oct 27, 2012, at 10:32 AM, Benjamin Kramer <[hidden email]> wrote:

>
> On 27.10.2012, at 18:24, Benjamin Kramer <[hidden email]> wrote:
>
>>
>> On 27.10.2012, at 18:15, Sean Silva <[hidden email]> wrote:
>>
>>> How does this affect freestanding implementations?
>>
>> This transform is disabled with -fno-builtin or -ffreestanding.
>
> Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is too conservative. Currently -ffreestanding disables optimizing all builtin functions, just like -fno-builtin. However, the GCC manual says:
>
>> GCC requires the freestanding environment provide memcpy,memmove, memset and memcmp.
>
> Should we enable those functions selectively in a freestanding environment? LLVM will start optimizing calls to them, and turn loops into one of those functions if possible. I'm not sure if that behavior is acceptable with -ffreestanding.
>
> - Ben
> _______________________________________________
> llvm-commits mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev