[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