Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] tbaa.struct metadata and variable sized structs"
2013 Oct 12
0
[LLVMdev] dragonegg: switch from old TBAA format to the new struct-path aware TBAA format
Hi Manman, thanks for the heads up. I looked into what it would take to produce
full struct TBAA metadata from the GCC aliasing info (GCC has aliasing info for
struct types, in fact for any type), but it looks kind of tricky. The problem
is the "offset" field, which doesn't exist in GCC. In GCC the aliasing
information forms a DAG, with a node for each type, plus a special root
2013 Oct 08
2
[LLVMdev] dragonegg: switch from old TBAA format to the new struct-path aware TBAA format
Hi Duncan,
I am hoping to remove the support for the old TBAA format soon.
You should be able to switch to the new format by replacing
MDNode *AliasTag = MDHelper.createTBAANode(TreeName, getTBAARoot());
with
MDNode *AliasType = MDHelper.createTBAAScalarTypeNode(TreeName,
getTBAARoot());
MDNode *AliasTag = MDHelper.createTBAAStructTagNode(AliasType, AliasType, 0)
Also replacing
2013 Mar 12
2
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On 3/11/13 1:17 PM, Daniel Berlin wrote:
> On Mon, Mar 11, 2013 at 11:41 AM, Manman Ren <mren at apple.com> wrote:
>> Based on discussions with John McCall
>>
>> We currently focus on field accesses of structs, more specifically, on fields that are scalars or structs.
>>
>> Fundamental rules from C11
>> --------------------------
>> An object
2013 Mar 11
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Mon, Mar 11, 2013 at 11:41 AM, Manman Ren <mren at apple.com> wrote:
> Based on discussions with John McCall
>
> We currently focus on field accesses of structs, more specifically, on fields that are scalars or structs.
>
> Fundamental rules from C11
> --------------------------
> An object shall have its stored value accessed only by an lvalue expression that has one
2013 Nov 14
1
[LLVMdev] Looking for a new dragonegg maintainer
Hi all, I just don't have time to look after dragonegg properly any more, so I'm
looking for someone to care over the care and feeding of this project. This not
only means ensuring that it continues to compile and work, it also means
- making sure dragonegg makes use of new LLVM features (eg struct TBAA)
- making sure it works with new versions of GCC, and supports interesting new
GCC
2017 Oct 18
2
RFC: Generate plain !tbaa tags in place of !tbaa.struct ones
Hello,
The motivation behind this proposal is to make it possible to
propagate TBAA information through scalarizing transformations,
such as SROA, that rewrite accesses to aggregates, e.g., memcpy()
calls, into accesses to scalars, that is, load and store
instructions.
Currently, we decorate instructions that initialize and copy
aggregates with !tbaa.struct tags that generally cannot be
2019 Jun 04
2
llvm-ir: TBAA and struct copies
Hi,
I have a question about the current definition of TBAA (See [1]).
In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue)
For following c-alike code:
struct S { int dummy; short e, f; } x,y;
struct S* p = &x;
int foobar() {
x.f=42;
*p=y; //**** struct copy
return x.f;
}
We produce:
2013 Mar 13
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Tue, Mar 12, 2013 at 3:44 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>
> On 3/11/13 1:17 PM, Daniel Berlin wrote:
>>
>> On Mon, Mar 11, 2013 at 11:41 AM, Manman Ren <mren at apple.com> wrote:
>>>
>>> Based on discussions with John McCall
>>>
>>> We currently focus on field accesses of structs, more specifically, on
2013 Mar 12
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Mon, Mar 11, 2013 at 4:56 PM, Manman Ren <mren at apple.com> wrote:
>
> On Mar 11, 2013, at 4:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> On Mon, Mar 11, 2013 at 3:45 PM, Manman Ren <mren at apple.com> wrote:
>>>
>>> On Mar 11, 2013, at 2:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>>
>>>> On
2017 Oct 31
2
RFC: Generate plain !tbaa tags in place of !tbaa.struct ones
In short, the problem with !tbaa.struct is that in most cases it cannot
be converted to !tbaa. For transformations like SROA this means they
cannot propagate !tbaa.struct tags for aggregate-accessing instructions
like memcpy() calls to the resulting loads and stores.
On 31/10/17 05:11, Hal Finkel wrote:
>
> On 10/18/2017 05:49 AM, Ivan Kosarev via llvm-dev wrote:
>> Hello,
2013 Mar 11
5
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
Based on discussions with John McCall
We currently focus on field accesses of structs, more specifically, on fields that are scalars or structs.
Fundamental rules from C11
--------------------------
An object shall have its stored value accessed only by an lvalue expression that has one of the following types: [footnote: The intent of this list is to specify those circumstances in which an
2019 Jun 05
2
llvm-ir: TBAA and struct copies
Hi Ivan,
The code that we have is indeed different from what the 'standard llvm' expects. Let me explain:
in our version we came into this situation in two steps:
1) I added support for 'special types' that map directly to types supported by hardware.
These types are represented by a struct containing a single iXXX member, providing the necessary bits
of the type, and at the
2013 Mar 11
2
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Mar 11, 2013, at 1:17 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> On Mon, Mar 11, 2013 at 11:41 AM, Manman Ren <mren at apple.com> wrote:
>> Based on discussions with John McCall
>>
>> We currently focus on field accesses of structs, more specifically, on fields that are scalars or structs.
>>
>> Fundamental rules from C11
>>
2013 Mar 11
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Mon, Mar 11, 2013 at 2:06 PM, Manman Ren <mren at apple.com> wrote:
>
> On Mar 11, 2013, at 1:17 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> On Mon, Mar 11, 2013 at 11:41 AM, Manman Ren <mren at apple.com> wrote:
>>> Based on discussions with John McCall
>>>
>>> We currently focus on field accesses of structs, more
2013 Mar 11
2
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Mar 11, 2013, at 4:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> On Mon, Mar 11, 2013 at 3:45 PM, Manman Ren <mren at apple.com> wrote:
>>
>> On Mar 11, 2013, at 2:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>>> On Mon, Mar 11, 2013 at 2:06 PM, Manman Ren <mren at apple.com> wrote:
>>>>
>>>>
2012 Aug 23
1
[LLVMdev] bending the limits of tbaa metadata
Hi,
I work on DDC, the compiler of a research Haskell dialect, Disciple (disciple.ouroborus.net (http://disciple.ouroborus.net)). We are looking to make use of LLVM's type-based alias analysis metadata to encode non-aliasing information between variables. We have found that the tbaa structure is somewhat limited in its expressivity. In particular we couldn't encode intransitive
2013 Mar 12
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Tue, Mar 12, 2013 at 10:10 AM, Manman Ren <mren at apple.com> wrote:
>
> On Mar 11, 2013, at 7:52 PM, Daniel Berlin wrote:
>
>> On Mon, Mar 11, 2013 at 4:56 PM, Manman Ren <mren at apple.com> wrote:
>>>
>>> On Mar 11, 2013, at 4:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>>
>>>> On Mon, Mar 11, 2013 at 3:45 PM,
2017 Oct 31
1
RFC: Generate plain !tbaa tags in place of !tbaa.struct ones
To clarify further, what this paper proposes is to use !tbaa for all
kinds of accesses, including aggregate ones, so we don't need to bother
trying to convert them when an aggregate access becomes a series of
scalar accesses or vice versa. As I said, in most cases such conversions
are not possible anyway, because !tbaa.struct tags do not refer to the
type of the aggregate itself and only
2014 Dec 02
2
[LLVMdev] TBAA vs !invariant.load metadata semantics
> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote:
>
> (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. )
>
> Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return
2015 Apr 09
2
[LLVMdev] TBAA metadata
Hi
I do not really understand why frontend generated TBAA metadata is
needed for the TBAA pass to work. It seems to me that we can always go
up the IR chain and find the base type from which the pointer is
derived from. Take the following example.
I know %0 = load i32, i32* %a, align 4, !tbaa !1 and store i32
%i.02, i32* %b, align 4, !tbaa !6
do not alias as their metadata !1 = !{!2, !3, i64