Details
Details
- Reviewers
rjmccall hfinkel efriedma - Commits
- rGed141bab6300: [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue…
rGce601eedf60e: Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with…
rG0e528202b85c: [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue…
rC315984: [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue…
rC315739: Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with…
rC315731: [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue…
rL315984: [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue…
rL315739: Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with…
rL315731: [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue…
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
With this patch applied we fail on bootstrapping stages of release builds (meaning enabled TBAA).
The reason is that for some casts we do not generate TBAA info that corresponds to the target type and leave them with TBAA info for the cast's operand expression. This results in invalid TBAA access descriptors. For example, for the following store we generate a TBAA descriptor with S as the base type and unsigned as the access type while the expected descriptor shall have V as the base type and unsigned as the access type.
struct V { unsigned n; }; struct S { char bytes[4]; }; void foo(S *p) { ((V*)p->bytes)->n = 0; }
Comment Actions
I think probably the best solution is to track may-alias-ness explicitly in the TBAAAccessInfo instead of relying in the frontend on being able to distinguish things in the LLVM metadata.