Hello, I am currently writing my Master's Thesis on a topic regarding the analysis of memory safety and termination of LLVM programs. This includes alignments in LLVM IR, but I am not sure if I understand their semantics correctly. I have written a program (see attachment) which uses the instruction store i32 1, i32* %7, align 4 to store an integer at an address that I forced to be uneven, and compiled it with clang. The result is that the integer is stored exactly there, which I expected for alignment 1 but not for alignment 4. Changing the alignment to any other size does not have any effect. This leads to my questions: - Do alignments provide additional semantics to be obeyed by the compiler or are they just hints that can be ignored? - What is the semantics of alignments from the perspective of an IR analyzer as opposed to an IR emitter? - Can you give me an example where wrong alignments lead to undefined behavior? Kind regards, Jera -------------- next part -------------- A non-text attachment was scrubbed... Name: test1.c Type: application/octet-stream Size: 206 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/668a682d/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: test1.ll Type: application/octet-stream Size: 2082 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/668a682d/attachment-0001.obj>
On 4/15/14, 5:41 AM, Jera Hensel wrote:> Hello, > > I am currently writing my Master's Thesis on a topic regarding the > analysis of memory safety and termination of LLVM programs.Cool. Have you checked out the Memory Safety Menagerie? http://sva.cs.illinois.edu/menagerie/> This includes alignments in LLVM IR, but I am not sure if I understand > their semantics correctly. I have written a program (see attachment) > which uses the instruction > > store i32 1, i32* %7, align 4 > > to store an integer at an address that I forced to be uneven, and > compiled it with clang. The result is that the integer is stored > exactly there, which I expected for alignment 1 but not for alignment > 4. Changing the alignment to any other size does not have any effect. > > This leads to my questions: > > - Do alignments provide additional semantics to be obeyed by the > compiler or are they just hints that can be ignored?According to the language reference manual, having a dynamic pointer value that isn't aligned at the specified alignment is undefined behavior. The alignment is designed as a hint to the code generator that it can assume that the address will be at the specified alignment so that it can generate more efficient code. This is useful on processors that have different memory access instructions for different word sizes (I think ARM is an example; I am sure there are others).> - What is the semantics of alignments from the perspective of an IR > analyzer as opposed to an IR emitter?From your perspective, there's undefined behavior if the address in the load or store isn't aligned at the proper boundary. That said, you can probably cheat a little bit and look at what the code generator will do. On x86, for example, the alignment probably doesn't matter as nearly all x86 memory access instructions can access any alignment; the memory access may simply be slower than necessary.> - Can you give me an example where wrong alignments lead to undefined > behavior?On some processors, there are different memory access instructions for accessing memory of difference sizes and alignments. Using an address that isn't aligned properly would cause a fault. I think ARM does this. Regards, John Criswell> > Kind regards, > Jera > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/538d9f94/attachment.html>
> - Do alignments provide additional semantics to be obeyed by the compiler or are they just hints that can be ignored?As John said, hints. You should be able to replace all alignments by "align 1" without changing the output (assuming the code still compiles).> - What is the semantics of alignments from the perspective of an IR analyzer as opposed to an IR emitter? > - Can you give me an example where wrong alignments lead to undefined behavior?Well, at runtime some CPUs can be configured to raise an exception if the access is unaligned. That's pretty undefined. At compile time, I think we use alignments to convert "add %addr, 3" into "or %addr, 3" (and so on) in some cases. That wouldn't go well if the alignment was incorrect. There are probably other transformations too, any optimisation making use of that information is a candidate. Cheers. Tim.
On 2014-Apr-15, at 3:41, Jera Hensel <jera.hensel at gmail.com> wrote:> - Do alignments provide additional semantics to be obeyed by the compiler or are they just hints that can be ignored?Depends on where the alignment is used. For stores [1] it's a hint, as John and Tim said. For global variables [2] it's an additional semantic. [1]: http://llvm.org/docs/LangRef.html#store-instruction [2]: http://llvm.org/docs/LangRef.html#global-variables
On Tue, Apr 15, 2014 at 5:41 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:> > On 2014-Apr-15, at 3:41, Jera Hensel <jera.hensel at gmail.com> wrote: > > > - Do alignments provide additional semantics to be obeyed by the > compiler or are they just hints that can be ignored? > > Depends on where the alignment is used. For stores [1] it's a hint, as > John and Tim said. For global variables [2] it's an additional semantic. > > [1]: http://llvm.org/docs/LangRef.html#store-instruction > [2]: http://llvm.org/docs/LangRef.html#global-variables'align' on stores is not a hint: "Overestimating the alignment results in undefined behavior." Unaligned stores can trap on some ISAs (not many that matter), but I believe we also try to use this information to optimize %b to zero here: store i32* %p, i32 0, align 4 %i = ptrtoint i32* %p to i64 %b = and i64 %i, i64 3 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/61a24895/attachment.html>