Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
You're sure you just want a single TBAA tag on memcpy's? I would think that it might be useful to encode separate path information for the two operands.
Sure, but since it is not a trivial change we could first replace 'tbaa.struct' with 'tbaa' and then decide how to attach multiple TBAA tags to an instruction. I didn't think enough about it, but one way to do that is to have different kinds of TBAA tags for read and write accesses, in which case we could re-purpose the 'tbaa.struct' tag slot.
Yes, I think that's fine.
I think unconditionally attaching the tag is probably wrong; you need suppress it in the may_alias cases. I'll grant that the existing code doesn't honor that, but that seems like a bug we should go ahead and fix. You'll need to either propagate more information into this function or propagate out the memcpy instruction so that callers can decide how to apply TBAA.
OK, I'm reading your response so that this patch may significantly increase the number of cases where we propagate TBAA tags from memory-transfer intrinsic calls, which means potentially more cases where ignoring may_alias would lead to problems. If so, then I tend to agree. Will prepare another version. Thanks.
- Supported propagation of TBAA info for aggregate transfers.
- Added tests on copying of may_alias aggregates.
Thank you. Maybe there should be an overload of EmitAggregateCopy that takes LValues? A lot of these cases start with an LValue on at least one side, and there are already some convenience functions to turn an Address into a naturally-typed LValue.
The copying functions changed to take LValues. It seems Address-taking versions are not very useful so we don't bother with overloading.