[LLVMdev] InstructionCombining forgets alignment of globals

[Nicolas Capens]

I think I found it. In InstCombiner::ComputeMaskedBits we have the following
lines:

 

  if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {

    unsigned Align = GV->getAlignment();

    if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) 

      Align = TD->getPrefTypeAlignment(GV->getType()->getElementType());

 

It assumes that global values are always optimally aligned. I think this is
incorrect and the bottom two lines should be removed.

 

However, I do think it's useful to specify the alignment at the time of
GlobalValue creation, so I propose to add a constructor with an Alignment
argument.

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Nicolas Capens
Sent: Thursday, 10 July, 2008 12:18
To: 'LLVM Developers Mailing List'
Subject: [LLVMdev] InstructionCombining forgets alignment of globals

 

Hi all,

 

The InstructionCombining pass causes alignment of globals to be ignored.

 

I've attached a replacement of Fibonacci.cpp which reproduces this (I used
2.3 release). Here's the x86 code it produces:

 

03C20019  movaps      xmm0,xmmword ptr ds:[164E799h] 

03C20020  mulps       xmm0,xmmword ptr ds:[164E79Ah] 

03C20027  movaps      xmmword ptr ds:[164E799h],xmm0 

03C2002E  mov         esp,ebp 

03C20030  pop         ebp  

03C20031  ret          

 

All three SSE instructions will generate a fault for accessing unaligned
memory. Disabling InstructionCombining gives me the following correct code:

 

03B10010  push        ebp  

03B10011  mov         ebp,esp 

03B10013  and         esp,0FFFFFFF0h 

03B10019  movups      xmm0,xmmword ptr ds:[164E79Ah] 

03B10020  movups      xmm1,xmmword ptr ds:[164E799h] 

03B10027  mulps       xmm1,xmm0 

03B1002A  movups      xmmword ptr ds:[164E799h],xmm1 

03B10031  mov         esp,ebp 

03B10033  pop         ebp  

03B10034  ret    

 

Unless I'm missing something this is quite clearly a bug. I'll give it a try
to locate the faulty code but all help is very welcome.

 

Cheers,

 

Nicolas Capens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080710/ac6020d5/attachment.html>