Pankaj Gode
2012-Apr-19 12:39 UTC
[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>
Duncan Sands
2012-Apr-19 13:17 UTC
[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass
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.> 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 <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Pankaj Gode
2012-Apr-19 13:49 UTC
[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass
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 :( . As suggested I have also enabled assertions and debug mode. Regards, Pankaj ________________________________ From: Duncan Sands <baldrick at free.fr> To: llvmdev at cs.uiuc.edu Sent: Thursday, April 19, 2012 6:47 PM Subject: Re: [LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass 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.> 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 <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev_______________________________________________ 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/20120419/bb8dd3f0/attachment.html>
Seemingly Similar Threads
- [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
- [LLVMdev] GetElementPtrInst Again!