llvm dev - Dec 2013 - [LLVMdev] Question about GetElementPtr Instruction Decomposition and Analysis in BasicAliasAnalysis

As the function DecomposeGEPExpression said,if const Value V is a symbolic
pointer expression, decompose it into a base pointer with a constant offset and
a number of scaled symbolic offsets.
Usually it is right,but once in 32bit poiter,and the offset is
0x80000000(0x80000000+0x80000000),
the result sounds not right.
  In my case,the IR series like this:
      getelementptr
      ...
     %a.sroa.0.0.idx= getelementptr inbouds[1x%union.int_union]*a,i32
-13421778,i32 -13421778
     ...
   As the result,the BaseOffs is -13421778(0x80000000) +
-13421778(0x80000000)=0x100000000.
They point to different addresses,so there isn't alias between them.But in
actual situation,for 32bit
target(such as i586),0x100000000 is overflow,the actual result is
-13421778(0x80000000) +
-13421778(0x80000000)=0.
    I try to trunk BaseOffs for 32bit target like this,am i right?
+ if(TD->getPoitersizeInBits() == 32)
+  BaseOffs = (int32_t) BaseOffs;
I would appreciate any suggestions on this.Thanks very much!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131222/3dc66aa7/attachment.html>

Hi Huyan(?),

On the whole it sounds like you've found a real bug, but your question
was a little vague for us to give a definitive response.
>     I try to trunk BaseOffs for 32bit target like this,am i right?
> + if(TD->getPoitersizeInBits() == 32)
> +  BaseOffs = (int32_t) BaseOffs;
Could you give (attach) a simple .ll file (& llc/opt command-line)
that triggers this, and tell us where you're thinking of making this
change? I'm rather worried about the implicit "64 || 32 bit"
dichotomy
introduced, so the code you've posted is suspect.

Cheers.

Tim.