Patch to force SuitableAlign's alignment when loading on object with larger alignment

[jahanian]

On Aug 4, 2014, at 5:39 PM, John McCall <rjmccall at apple.com> wrote:

> On Aug 4, 2014, at 2:58 PM, jahanian <fjahanian at apple.com> wrote:
>> New patch which is a simplified version of the previous patch. Simplified by using the existing
>> isAlignmentRequired. No other changes.
> 
> +VALUE_LANGOPT(MaxTypeAlign  , 32, 0,
> +              "default maximum alignment for types")
> 
> +def fmax_type_align_EQ : Joined<["-"], "fmax-type-align=">, Group<f_Group>, Flags<[CC1Option]>,
> +  HelpText<"Specify the default maximum alignment for types">;
> +def fno_max_type_align : Flag<["-"], "fno-max-type-align">, Group<f_Group>;
> 
> I wordsmithed the option name and help text a little with Doug, and we settled on this:
> 
>  -fmax-unknown-pointer-align=N
>    “Specify the maximum alignment to enforce on pointers lacking an explicit alignment"
> 
> You should also document this in docs/UsersManual.rst, in the Controlling
> Code Generation section.  I would recommend the following text:
> 
>  -fmax-unknown-pointer-align=[number]
>  -fno-max-unknown-pointer-align
>    Instruct the code generator to not enforce a higher alignment than the given
>    number (of bytes) when accessing memory via an opaque pointer or reference.
>    This cap is ignored when directly accessing a variable or when the pointee
>    type has an explicit “aligned” attribute.
> 
>    The value should usually be determined by the properties of the system allocator.
>    Some builtin types, especially vector types, have very high natural alignments;
>    when working with values of those types, Clang usually wants to use instructions
>    that take advantage of that alignment.  However, many system allocators do
>    not promise to return memory that is more than 8-byte or 16-byte-aligned.  Use
>    this option to limit the alignment that the compiler can assume for an arbitrary
>    pointer, which may point onto the heap.
> 
>    This option does not affect the ABI alignment of types; the layout of structs and
>    unions and the value returned by the alignof operator remain the same.
> 
>    This option can be overridden on a case-by-case basis by putting an explicit
>    “aligned” alignment on a struct, union, or typedef.  For example:
> 
>   ::
>       #include <immintrin.h>
>       // Make an aligned typedef of the AVX-512 16-int vector type.
>       typedef __v16si __aligned_v16si __attribute__((aligned(64)));
> 
>       void initialize_vector(__aligned_v16si *v) {
>         // The compiler may assume that ‘v’ is 64-byte aligned, regardless of the
>         // value of -fmax-unknown-pointer-align.
>       }
> 
> +  ASTContext &Context = CGM.getContext();
> +  if (const UnaryOperator *UOPE = dyn_cast<UnaryOperator>(E))
> +    if (UOPE->getOpcode() == UO_Deref) {
> 
> This is far too specific.  In your first patch, you were modifying
> MakeNaturalAlignAddrLValue, which I think was fine; why did you
> change your mind?

Checked in r214911. Please do a post-commit review.
- Thanks, Fariborz

> 
> John.

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