I've heard from a few people that placement new is going to be handled by LLVM using the llvm.invariant.group.barrier intrinsic; however, the documentation for that intrinsic seems to indicate that it deals with only invariant.group metadata and not TBAA metadata. I would like to understand how the solution would work in the context of https://llvm.org/bugs/show_bug.cgi?format=multiple&id=28767. -- HT -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161124/830f53b6/attachment.html>
What is the purpose of the union there? I ask because pretty much no compiler will respecting the unioning without visible accesses in all cases, because it would ruin most optimization[1] But i'm also not sure it's required in this testcase to make your testcase fail. In practice, handling placement new properly in gcc required the equivalent of a new intrinsic (in gcc, it required adding CHANGE_DYNAMIC_TYPE_EXPR). [1] For example, you can pretty much get every compiler out there to generate "wrong" code using unions and strict aliasing, see the last discussion we had about this on the mailing list (subject line had "wrong results with union and strict-aliasing"). On Thu, Nov 24, 2016 at 2:40 PM, Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I've heard from a few people that placement new is going to be handled by > LLVM using the llvm.invariant.group.barrier intrinsic; however, the > documentation for that intrinsic seems to indicate that it deals with only > invariant.group metadata and not TBAA metadata. > > I would like to understand how the solution would work in the context of > https://llvm.org/bugs/show_bug.cgi?format=multiple&id=28767. > > -- HT > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161124/98c4ac97/attachment.html>
On Fri, Nov 25, 2016 at 1:42 AM, Daniel Berlin <dberlin at dberlin.org> wrote:> What is the purpose of the union there? >The purpose of the union is to increase portability by ensuring that the placement new is not being performed on insufficiently sized or aligned memory.> I ask because pretty much no compiler will respecting the unioning without > visible accesses in all cases, because it would ruin most optimization[1] > > But i'm also not sure it's required in this testcase to make your testcase > fail. >It isn't. The program should be valid, without the union, on platforms where int and float have the same size an alignment.> > In practice, handling placement new properly in gcc required the > equivalent of a new intrinsic (in gcc, it required adding > CHANGE_DYNAMIC_TYPE_EXPR). >Sure; my question is whether or not there is already a solution in the works for LLVM. If not, then I'll try to work with some folks to propose an intrinsic. -- HT -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161125/a74afe70/attachment.html>