llvm dev - Sep 2014 - [LLVMdev] How to deal with wider Integer type?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140904/7601277d/attachment.html>

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/20140903/eb74f602/attachment.html>

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>