llvm dev - Apr 2012 - [LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

Hi All,
 
I have been having this issue, when I am enable Instruction Combining pass, for
an application.
I have read similar post ealier,
http://old.nabble.com/Instruction-Combining-Pass-*Breaking*-Struct-Reads--td24253572.html
With reference to the above case, my target data layout is defined as:
DataLayout("e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-a:32:32")
Thus I don't see problem mentioned in the above reference.
 
In the function "visitGetElementPtrInst" has a piece of code for
handling bitcasts,
   /// See if we can simplify:
  ///   X = bitcast A* to B*
  ///   Y = gep X, <...constant indices...>
which when commented, does not give me problem.
 
The application uses a buffer.  This buffer is assigned to struct such as
"FRAME_DATA", instead of allocating space for struct and then using it
(I think, this is some kind of good usage of memory). 
 
Detailng further in the application,
The used buffer is a 16 bit pointer, declared as: 
#define SAMPLE 1024
>> Word16 Data[4*SAMPLE];                  /*!< Output buffer */
Elements of this buffer are initialized to 0 in main function./* initialize time
data buffer */
        for (i=0; i < 4*SAMPLE; i++){
                Data[i] = 0;
        }

This filled buffer is then passed to various functions, on it's journey
handling data at various instance of time about frames.
These functions use this buffer, by assiging to appropriate struct pointers
(memory reusing probably).
 
   frameDLt  = (FRAME_DATA*) &Data[MAX_SIZE];
   frameDRt  = (FRAME_DATA*) &Data[3*MAX_SIZE];

Where frameDLt and frameDRt are struct pointers to 
"FRAME_DATA *frameDLt;" and "SBR_FRAME_DATA *frameDRt;"
 
The struct is defined as:
 
 %struct._FRAME_DATA = type { i16, %struct._FRAME_INFO, [5 x i16], [2 x i16], [5
x i32], i32, i16, [48 x i32], i16, [240 x i16], [10 x i16] }
 %struct._FRAME_INFO = type { i16, i16, [6 x i16], [5 x i16], i16, i16, [3 x
i16] }
 
The code generated, when trying to access "coupling, a member 16 bit
variable of struct", "without instruction combining" is:
 
%coupling = getelementptr inbounds %struct._FRAME_DATA* %2, i32 0, i32 5, !dbg
!575
  store i32 0, i32* %coupling, align 4, !dbg !575
 
 
And the code generated "with instruction combining" is:
%coupling = getelementptr inbounds i16* %timeData, i32 1060, !dbg !575
  %24 = bitcast i16* %coupling to i32*, !dbg !575
  store i32 0, i32* %24, align 4, !dbg !575
 
 
The FRAME_DATA, is defined as:
typedef struct _FRAME_DATA
{
  Word16 nScaleFactors;                    /*!< total number of scalefactors
in frame */
  FRAME_INFO frameInfo;                 /*!< time grid for current frame */
  Word16 domain_vec[MAX_ENVELOPES];  /*!< Bitfield containing direction of
delta-coding for each envelope */
  Word16 domain_vec_noise[MAX_NOISE_ENVELOPES]; /*!< Same as above, but for
noise envelopes */
  INVF_MODE sbr_invf_mode[MAX_INVF_BANDS]; /*!< Strength of filtering in
transposer */
  COUPLING_MODE coupling;               /*!< Stereo-mode */ 
  Word16 ampResolutionCurrentFrame;        /*!< Amplitude resolution of
envelope values (0: 1.5dB, 1: 3dB) */
  Flag addHarmonics[MAX_FREQ_COEFFS];   /*!< Flags for synthetic sine
addition */
  Word16 maxQmfSubbandAac;       /*!< Solves the 'undefined x-over
problem' for the enhancement */
  Word16 iEnvelope[MAX_NUM_ENVELOPE_VALUES];       /*!< Envelope data */
  Word16 sbrNoiseFloorLevel[MAX_NUM_NOISE_VALUES]; /*!< Noise envelope data
*/
}
FRAME_DATA;
COUPLING_MODE is a enum. 

the element ptr address calculated by GEP is different in above cases:
 
1. without instruction combining
coupling member variable, is at:
  %struct._FRAME_DATA* %2, i32 0, i32 5
 
i.e. at 5 offset in FRAME_DATA i.e. the 6th element, i.e. coupling member
variable.
Why it is "i32 5" is? If we see this structure has some elements of
size i32, so as per C guidelines, other elements will be padded to i32.
In terms of i16, the offset should have been, 
i16, i16, i16, [6 x i16], [5 x i16], i16, i16, [3 x i16], [5x i16], [2 x i16],
[5 x i32], i32 ,....
31 words = 124 bytes.(considering it is aligned to i32)
 
2. with instruction combining
coupling is at:
i16* %timeData, i32 1060
i.e. 1060 bytes  offset. 
This is no way close to what is being referred by "without instruction
combining".
 
 
I felt, the problem with this is the way llvm instruction combining handles
generation of offset for a such a situation.
As I am not sure, I wanted to know more about this. 
 
 
Regards,
Pankaj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120417/648c0454/attachment.html>

Hi Pankaj, your best bet is to send the entire bitcode before and after
instcombine runs.

Ciao, Duncan.

With reference to the previous query,
I think, i miscalculated the offset, just recalculating.

1. without instruction combining
coupling member variable, is at:
  %struct._FRAME_DATA* %2, i32 0, i32 5
  where "%2" is defined as:
  %arrayidx3 = getelementptr inbounds i16* %Data, i32 1024, !dbg !446
  %2 = bitcast i16* %arrayidx3 to %struct._FRAME_DATA*, !dbg !446

i.e. at 5 offset in FRAME_DATA i.e. the 6th element, i.e. coupling member
variable.

i16, i16, i16, [6 x i16], [5 x i16], i16, i16, [3 x i16], [5x i16], [2 x i16],
[5 x i32], i32 ,....
31 words = 124 bytes.(considering it is aligned to i32)
1024 + 31 = 1055 

2. with instruction combining
coupling is at:
i16* %timeData, i32 1060
i.e. 1060  offset. 

Still the location references by "without instruction combining" is
5 less from with instruction combining.

Earlier when I was using llvm2.9, instruction combining does not give me any
problem.  And similar code is generated as with llvm 3.0 instruction combining.


Is there any point where I can check for the exact issue? 


Regards,
Pankaj

 



________________________________
From: Duncan Sands <baldrick at free.fr>
To: llvmdev at cs.uiuc.edu 
Sent: Tuesday, April 17, 2012 5:07 PM
Subject: Re: [LLVMdev] Issue with GetElementPtrInst in Instruction Combining
pass

Hi Pankaj, your best bet is to send the entire bitcode before and after
instcombine runs.

Ciao, Duncan.
_______________________________________________
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/20120417/3e30a4ef/attachment.html>