On Aug 4, 2014, at 5:39 PM, John McCall <[email protected]> wrote: > On Aug 4, 2014, at 2:58 PM, jahanian <[email protected]> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
