[LLVMdev] More info, was Help needed after hiatus

Richard Pennington rich at pennware.com
Sat May 17 14:41:22 PDT 2008


Eli Friedman wrote:
> On Sat, May 17, 2008 at 11:34 AM, Richard Pennington <rich at pennware.com> wrote:
[snip]
> BTW, It's usually better to file a bug for this sort of thing.

I just got a Bugzilla account. I will file a bug next time. Anton did it 
for me this time. (Thanks Anton!)
> 
> The issue is around InstructionCombining:2507:
>   // W*X + Y*Z --> W * (X+Z)  iff W == Y
>   if (I.getType()->isIntOrIntVector()) {
>     Value *W, *X, *Y, *Z;
>     if (match(LHS, m_Mul(m_Value(W), m_Value(X))) &&
>         match(RHS, m_Mul(m_Value(Y), m_Value(Z)))) {
> 
> The issue starts with the lines:
>         add i32 %2, 2           ; <i32>:3 [#uses=1]
>         mul i32 %3, ptrtoint (i32* getelementptr (i32* null, i32 1) to
> i32)             ; <i32>:4 [#uses=1]
> 
> Roughly, the multiplication gets distributed, resulting in something
> like (loaded value) * (ptrtointexpr) + 2 * (ptrtointexpr).  This gets
> matched by the match, which then reverses the transformation.  This,
> of course, gets matched by the code to distribute the multiply,
> resulting in a never-ending cycle.

Thanks for the explanation.

> 
> A side note: I know I've seen suggestions that "ptrtoint (i32*
> getelementptr (i32* null, i32 1) to i32)" is a suitable replacement
> for sizeof, but if it is supposed to be legal, the documentation for
> getelementptr should make that clear. I'm pretty sure the equivalent
> C, "((int*)0)+1", has undefined behavior.

I think that this is not undefined behavior unless the result is 
dereferenced. In particular, I think it would be a common way of 
implementing offsetof().

-Rich





More information about the llvm-dev mailing list