[LLVMdev] How to deal with wider Integer type?
Ruiling Song
ruiling.song83 at gmail.com
Thu Sep 4 01:41:52 PDT 2014
Some code in GVN.cpp:
static Value *CoerceAvailableValueToLoadType(Value *StoredVal,
Type *LoadedTy,
Instruction *InsertPt,
const DataLayout &DL) {
....
// Convert vectors and fp to integer, which can be manipulated.
if (!StoredValTy->isIntegerTy()) {
StoredValTy = IntegerType::get(StoredValTy->getContext(), StoreSize);
StoredVal = new BitCastInst(StoredVal, StoredValTy, "", InsertPt);
}
...
here if LoadedTy is Vector type like <4 x i32>, then StoreSize will be 128
bit integer.
I will show you some example later.
I find in pass ScalarReplAggregates it offers some configuration parameters
to control the maximum width of wide integer, which is quite friendly.
In SROA, i don't found that kind configuration parameters.
Can anybody familiar with 'Scalar' passes give some insights?
2014-09-04 14:23 GMT+08:00 Chandler Carruth <chandlerc at google.com>:
> Yes, the LLVM backend does type legalization on the SelectionDAG formed
> from the LLVM IR. This eliminates too-wide integer types by decomposing the
> operations.
>
> However, SROA never produces an integer wider than what was used in the
> input IR that I know of... I would be surprised if GVN did this either.
>
>
> On Wed, Sep 3, 2014 at 10:53 PM, Ruiling Song <ruiling.song83 at gmail.com>
> wrote:
>
>> Hi,
>>
>> I am currently working on an opencl project based on LLVM, the target
>> device is 32bit.
>> I met a problem that some llvm passes like GVN SROA will generate some IR
>> operating
>> on wide integer types like i128 or i512. But the device does not support
>> such kind of data type.
>> Is there any idea on how to lower this kind of IR to only operate on i32
>> or vector of i32? Or is there any existing code handle this?
>>
>> Thanks!
>> Ruiling
>>
>> _______________________________________________
>> 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/20140904/5039491e/attachment.html>
More information about the llvm-dev
mailing list