[llvm] r174336 - [Stack Alignment] emit warning instead of a hard error

[Jim Grosbach]

Hi Manman,

> Per discussion in rdar://13127907, we should emit a hard error only if
> people write code where the requested alignment is larger than achievable
> and assumes the low bits are zeros. A warning should be good enough when
> we are not sure if the source code assumes the low bits are zeros.

I'm a bit confused. This implies that we're doing the frontend analysis to check for that condition and issue a hard error for it. The below is saying that's not actually the case. Can you elaborate a bit on what exactly is happening?

-Jim

On Feb 5, 2013, at 10:18 AM, Manman Ren <mren at apple.com> wrote:

> 
> We currently do not analyze the source code to check the usage of the low bits.
> 
> In the backend, the alignment is already clamped to the correct value, so the backend optimizations will not treat those low bits as zero.
> 
> -Manman
> 
> On Feb 4, 2013, at 6:08 PM, Eric Christopher <echristo at gmail.com> wrote:
> 
>> Also I could be missing it but I couldn't spot the code that checks for the usage of the bits in not aligning/warning/erroring? Quick pointer?
>> 
>> Thanks!
>> 
>> -eric
>> 
>> 
>> On Mon, Feb 4, 2013 at 5:41 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>> 
>> 
>> On Mon, Feb 4, 2013 at 5:35 PM, Manman Ren <mren at apple.com> wrote:
>> 
>> Yes, there are related discussions in r169197 and "[PATCH] Stack Alignment: clamp the alignment of stack objects in MachineFrameInfo".
>> 
>> But people can use a 32-byte alignment attribute on a machine which only supports 16-byte stack alignment.
>> If the source code further assumes the low bits are zeros, they will get wrong result.
>> But if not, a hard error is too much and it will make existing code which can compile with earlier version failed to build with this patch.
>> 
>> And to use the other side of the argument that won last time :)
>> 
>> But this means that if people aren't looking at the warning or hard erroring on warnings then we're going to emit bad code instead of making it an error.
>> 
>> -eric
>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130205/d8c50e6d/attachment.html>