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

If this information is useful, please help other people find it:
Share via:

Pankaj Gode

2012-Apr-17 14:21 UTC

[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

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>

Pankaj Gode

2012-Apr-18 14:55 UTC

head link

[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

Hi All,
 
Further exploring the problem I could find that, there is a address offset
calculation problem, with the GEP bitcast handling code in instruction
combining.
Below is table which shows address offset calculation for the struct elements
(described earlier).
 
Type Variable Actual Size(in bytes) pass fail llvm2.9 
Address(pass) Size-pass (in bytes) Address (fail) Size -fail (in bytes) with
llvm2.9 Size (with llvm2.9)
short  nScaleFactors;  2 40ac0198 4 40ac0198 2 40ac0190 2 
FRAME_INFO  frameInfo; //struct described below 34 40ac019c 36 40ac019a 36
40ac0192 36
short  domain_vec[MAX_ENVELOPES];  10 40ac01c0 10 40ac01be 10 40ac01b6 10 
short  domain_vec_noise[MAX_NOISE_ENVELOPES];  4 40ac01ca 6 40ac01c8 4 40ac01c0
4
INVF_MODE  sbr_invf_mode[MAX_INVF_BANDS];  20 40ac01d0 20 40ac01cc 20 40ac01c4
20
COUPLING_MODE coupling;         //enum 4 40ac01e4 4 40ac01e0 4 40ac01d8 4 
short  ampResolutionCurrentFrame;        2 40ac01e8 4 40ac01e4 4 40ac01dc 4 
Flag  addHarmonics[MAX_FREQ_COEFFS]; //typedef int 192 40ac01ec 192 40ac01e8 192
40ac01e0 192
short  maxQmfSubbandAac;      2 40ac02ac 2 40ac02a8 2 40ac02a0 2 
short  iEnvelope[MAX_NUM_ENVELOPE_VALUES];       480 40ac02ae 480 40ac02aa 480
40ac02a2 480
short   sbrNoiseFloorLevel[MAX_NUM_NOISE_VALUES];  20 40ac048e   40ac048a  
40ac0482  
                
FrameInfo               
short     frameClass; 2           
short  nEnvelopes;    2           
short  borders[MAX_ENVELOPES+1];  12           
short  freqRes[MAX_ENVELOPES];   10           
short  tranEnv;   2           
short  nNoiseEnvelopes;  2           
short  bordersNoise[MAX_NOISE_ENVELOPES+1]; 4           
    34           
 
I am searching for reason, from where exactly this happens, but couldn't
find the exact place, for the fix.
If somebody is aware of this, it would be helpful.
 
Additionally, though same offsets are generated for the structure, but
it works with llvm2.9. I am not sure, if there was any change for this elsewhere
which affects this portion of instruction combining.
 
 
Regards,
Pankaj
 
 
P.S. comma separate text, for the table is below:
Type,Variable,Actual Size(in bytes),pass,,fail,,llvm2.9,
,,,Address(pass),Size-pass (in bytes),Address (fail),Size -fail (in bytes),with
llvm2.9,Size (with llvm2.9)
short, nScaleFactors; ,2,40ac0198,4,40ac0198,2,40ac0190,2
FRAME_INFO ,frameInfo; //struct described
below,34,40ac019c,36,40ac019a,36,40ac0192,36
short ,domain_vec[MAX_ENVELOPES]; ,10,40ac01c0,10,40ac01be,10,40ac01b6,10
short ,domain_vec_noise[MAX_NOISE_ENVELOPES];
,4,40ac01ca,6,40ac01c8,4,40ac01c0,4
INVF_MODE ,sbr_invf_mode[MAX_INVF_BANDS];
,20,40ac01d0,20,40ac01cc,20,40ac01c4,20
COUPLING_MODE,coupling;         //enum,4,40ac01e4,4,40ac01e0,4,40ac01d8,4
short ,ampResolutionCurrentFrame;       ,2,40ac01e8,4,40ac01e4,4,40ac01dc,4
Flag ,addHarmonics[MAX_FREQ_COEFFS]; //typedef
int,192,40ac01ec,192,40ac01e8,192,40ac01e0,192
short ,maxQmfSubbandAac;     ,2,40ac02ac,2,40ac02a8,2,40ac02a0,2
short,
iEnvelope[MAX_NUM_ENVELOPE_VALUES];      ,480,40ac02ae,480,40ac02aa,480,40ac02a2,480
short ,sbrNoiseFloorLevel[MAX_NUM_NOISE_VALUES];
,20,40ac048e,,40ac048a,,40ac0482,
,,,,,,,,
FrameInfo,,,,,,,,
short    ,frameClass;,2,,,,,,
short ,nEnvelopes;   ,2,,,,,,
short ,borders[MAX_ENVELOPES+1]; ,12,,,,,,
short ,freqRes[MAX_ENVELOPES];  ,10,,,,,,
short, tranEnv;  ,2,,,,,,
short ,nNoiseEnvelopes; ,2,,,,,,
short ,bordersNoise[MAX_NOISE_ENVELOPES+1];,4,,,,,,
,,34,,,,,,
 
 
 


________________________________
From: Pankaj Gode <godepankaj at yahoo.com>
To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> 
Sent: Tuesday, April 17, 2012 7:51 PM
Subject: Re: [LLVMdev] Issue with GetElementPtrInst in Instruction Combining
pass


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



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/20120418/72ce09e3/attachment.html>

Pankaj Gode

2012-Apr-19 12:39 UTC

head link

[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

I think, finally, I want to conclude on this.
 
The problem I see is that if I comment the case for "simplificaiton of
bitcast to gep of original struct in instruction combining", wherein there
is a case for if the offset by which GEP moves the pointer is non-zero.
 
If I disable this code, then structure elements size, I get is
--------------------------------------------------------------------------------------------
Type       | struct elements                      | Size in bytes | Correct size
in bytes
--------------------------------------------------------------------------------------------
short          nScaleFactors                               4            2
FRAME_INFO     frameInfo                                  36           36
short          domain_vec[MAX_ENVELOPES]                  10           10
short          domain_vec_noise[MAX_NOISE_ENVELOPES]       6            4
INVF_MODE      sbr_invf_mode[MAX_INVF_BANDS]              20           20
COUPLING_MODE  coupling                                    4            4
short          ampResolutionCurrentFrame                   2            2
Flag           addHarmonics[MAX_FREQ_COEFFS]             192          192
short          maxQmfSubbandAac                            2            2
short          iEnvelope[MAX_NUM_ENVELOPE_VALUES]        480          480
short          sbrNoiseFloorLevel[MAX_NUM_NOISE_VALUES]   20           20
--------------------------------------------------------------------------------------------
Though the size i get is wrong, but still my application passes. I don't
have any reason for that though.
 
But, if I enable this code, then the structure elements size, I get is:
--------------------------------------------------------------------------------------------
Type       | struct elements                      | Size in bytes | Correct size
in bytes
--------------------------------------------------------------------------------------------
short          nScaleFactors                               2            2
FRAME_INFO     frameInfo                                  36           36
short          domain_vec[MAX_ENVELOPES]                  10           10
short          domain_vec_noise[MAX_NOISE_ENVELOPES]       4            4
INVF_MODE      sbr_invf_mode[MAX_INVF_BANDS]              20           20
COUPLING_MODE  coupling                                    4            4
short          ampResolutionCurrentFrame                   2            2
Flag           addHarmonics[MAX_FREQ_COEFFS]             192          192
short          maxQmfSubbandAac                            2            2
short          iEnvelope[MAX_NUM_ENVELOPE_VALUES]        480          480
short          sbrNoiseFloorLevel[MAX_NUM_NOISE_VALUES]   20           20
--------------------------------------------------------------------------------------------
 
These sizes are the same as I get with llvm2.9 and which matches with
expected/correct as well. For llvm2.9, my test passes as well with these sizes.
 
So I wanted to know, if there is a major change in llvm infrastructure required
to calculate this offset/size for each structure element or something related to
this? 
 
If nothing is changed related to this, i will simply comment out this code, as
after commenting, it works for me and forget the problem.
 
 
Regards,
Pankaj
 
 
_______________________________________________LLVM Developers mailing
listLLVMdev at cs.uiuc.edu       
http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120419/5f7321dc/attachment.html>

Apparently Analagous Threads

Search for more apparently analagous threads

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

[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass

Apparently Analagous Threads