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>
On Thu, Sep 4, 2014 at 1:41 AM, Ruiling Song <ruiling.song83 at gmail.com> wrote:> 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. >The configuration parameters in the old ScalarReplAggregates pass is because it would create *insane* things like i4096s. =/ When I wrote SROA to replace it, this was actually the motivating principle -- it doesn't introduce new integer type sizes, it uses the sizes that are already being loaded and stored.> Can anybody familiar with 'Scalar' passes give some insights? >=] I'm quite familiar with the SROA ones. GVN I know less about. The code you cite from GVN certainly looks fishy to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140904/a3e44cfa/attachment.html>
Do you mean that SROA pass will not do some conversion like <4 x i32 > to i128 if the input IR does not contain i128? If not, then how the SROA Scalarize a <4 x i32> instruction? As from my understanding, Scalarize is to change a vector/array type into a simple integer type. Am I right? 2014-09-04 16:48 GMT+08:00 Chandler Carruth <chandlerc at google.com>:> > On Thu, Sep 4, 2014 at 1:41 AM, Ruiling Song <ruiling.song83 at gmail.com> > wrote: > >> 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. >> > > The configuration parameters in the old ScalarReplAggregates pass is > because it would create *insane* things like i4096s. =/ When I wrote SROA > to replace it, this was actually the motivating principle -- it doesn't > introduce new integer type sizes, it uses the sizes that are already being > loaded and stored. > > >> Can anybody familiar with 'Scalar' passes give some insights? >> > > =] I'm quite familiar with the SROA ones. GVN I know less about. The code > you cite from GVN certainly looks fishy to me. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140910/17b85118/attachment.html>