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,–td24253572.html
With reference to the above case, my target data layout is defined as:
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[4SAMPLE]; /!< 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 */
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)

  1. 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.


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

  1. 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?


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)

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

sbrNoiseFloorLevel[MAX_NUM_NOISE_VALUES]; 20 40ac048e 40ac048a 40ac0482

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

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.


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,

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

Hi Pankaj, are you testing this on valid bitcode? The bitcode you sent me did
not pass the verifier, i.e. was not valid. Optimizers can be expected to do
strange and wrong things if passed invalid bitcode. That is not a bug in LLVM:
it is user error if a user doesn't use valid bitcode.

Ciao, Duncan.

Yes, it is valid bit code. The command you gave does not give any error to me.
Actually there is some company specific information and functions in it for the concerned file, so I was not able to share the complete code.
I don’t know what I can remove and share so that it is valid and shareable as well :frowning: .

As suggested I have also enabled assertions and debug mode.