search for: may_alias

...your take on this then: >> >> /* The Intel API is flexible enough that we must allow aliasing with >> other >> vector types, and their scalar components. */ >> /* APPLE LOCAL 4505813 */ >> typedef long long __m64 __attribute__ ((__vector_size__ (8), >> __may_alias__)); > > This is actually completely different AFAIK, That statement was that: > float4 a; > float* ptr_z = (float*)(&a) + 3; ``violates strict aliasing`` That assertion is wrong. The docs says: @item may_alias Accesses to objects with types with this attribute are not subject...

...; Similarly to the scalar and struct-path approaches, we consider > every type to be a member of a type group it explicitly refers > to. Here's how the tree that describes relations between type > groups would look like for the example above: > > <tbaa_root> > |- <may_alias> > |- <representation_byte> > |-<structure> > | |- S > |- int > > The <vtable_pointer> group has a special meaning and is used to > describe accesses to virtual table pointers. As in the current scheme, this group is a peer to <ma...

It's hard to say. What you've described sounds close to a neutral type system implemented in metadata. In particular, ". It also defines a set of language-neutral formal rules that LLVM codegen follows to determine whether a given pair of accesses are allowed to overlap by rules of the input language. " and "the base type followed by field descriptors" etc Despite the

Hey all, Could anyone give me any hint on how llvm-g++ translates the "__attribute__" annotations (supported by GCC)? (Has GCC already implemented the support for the C++0x attributes?) Suppose a class definition as below: template <typename T> class __attribute__((may_alias)) list { ... }; I understand that each particular attribute may be handled differently. Assuming that I want to retain one attribute in the LLVM IR, how is the attribute represented in the LLVM IR? And then how can I query the attribute assuming that the attribute is appertained to a class? By t...

...; Similarly to the scalar and struct-path approaches, we consider > every type to be a member of a type group it explicitly refers > to. Here's how the tree that describes relations between type > groups would look like for the example above: > > <tbaa_root> > |- <may_alias> > |- <representation_byte> > |-<structure> > | |- S > |- int > > The <vtable_pointer> group has a special meaning and is used to > describe accesses to virtual table pointers. Similarly, the > <union> type group includes all...

On Oct 14, 2008, at 11:43 PM, Mike Stump wrote: > That statement was that: > >> float4 a; >> float* ptr_z = (float*)(&a) + 3; > > ``violates strict aliasing`` > > That assertion is wrong. The docs says: > > @item may_alias > Accesses to objects with types with this attribute are not subjected > to > type-based alias analysis, but are instead assumed to be able to alias > any other type of objects, just like the @code{char} type. > > clearly, is _m64 is to be treated as char, then, all stores befor...

...r and struct-path approaches, we consider >> every type to be a member of a type group it explicitly refers >> to. Here's how the tree that describes relations between type >> groups would look like for the example above: >> >> <tbaa_root> >> |- <may_alias> >> |- <representation_byte> >> |-<structure> >> | |- S >> |- int >> >> The <vtable_pointer> group has a special meaning and is used to >> describe accesses to virtual table pointers. Similarly, the >> <un...

> -----Original Message----- > From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On > Behalf Of Michael Kruse > Sent: Wednesday, October 18, 2017 1:18 PM > To: Song, Ruiling <ruiling.song at intel.com> > Cc: Michael Kruse <llvm at meinersbur.de>; llvm-dev at lists.llvm.org > Subject: Re: Possible bug of Alias Analysis? > > 2017-10-18

...e > workaround with a union, though. Hum what's your take on this then: /* The Intel API is flexible enough that we must allow aliasing with other vector types, and their scalar components. */ /* APPLE LOCAL 4505813 */ typedef long long __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); :-)

.... > > Hum what's your take on this then: > > /* The Intel API is flexible enough that we must allow aliasing with > other > vector types, and their scalar components. */ > /* APPLE LOCAL 4505813 */ > typedef long long __m64 __attribute__ ((__vector_size__ (8), > __may_alias__)); This is actually completely different AFAIK, this allows things like: ((float*)&myvec4)[2] which is exactly what the proposal wants to continue supporting in the IR. -Chris

...> On Oct 14, 2008, at 11:43 PM, Mike Stump wrote: >> That statement was that: >> >>> float4 a; >>> float* ptr_z = (float*)(&a) + 3; >> >> ``violates strict aliasing`` >> >> That assertion is wrong. The docs says: >> >> @item may_alias >> Accesses to objects with types with this attribute are not subjected >> to >> type-based alias analysis, but are instead assumed to be able to >> alias >> any other type of objects, just like the @code{char} type. >> >> clearly, is _m64 is to be treate...

.../ + __u32 nr_items; + + /* align to 64 bits */ + __u32 unused; + + /* some extra for later */ + __u64 unused1; + __u64 unused2; + __u64 unused3; + __u64 unused4; +}; + +struct btrfs_ioctl_search_header { + __u64 transid; + __u64 objectid; + __u64 offset; + __u32 type; + __u32 len; +} __attribute__((may_alias)); + +#define BTRFS_SEARCH_ARGS_BUFSIZE (4096 - sizeof(struct btrfs_ioctl_search_key)) +/* + * the buf is an array of search headers where + * each header is followed by the actual item + * the type field is expanded to 32 bits for alignment + */ +struct btrfs_ioctl_search_args { + struct btrfs_ioc...