Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] scalarrepl fails to promote array of vector"
2012 Mar 12
3
[LLVMdev] scalarrepl fails to promote array of vector
Hi Chris,
Thanks for your reply.
You said that scalarRepl gets shy about loads and stores of the entire
aggregate. Then I use a test case:
; ModuleID = 'test1.ll'
define i32 @fun(i32* nocapture %X, i32 %i) nounwind uwtable readonly {
%stackArray = alloca <4 x i32>
%XC = bitcast i32* %X to <4 x i32>*
%arrayVal = load <4 x i32>* %XC
store <4 x i32>
2012 Mar 12
0
[LLVMdev] scalarrepl fails to promote array of vector
Hi Fan,
> You said that scalarRepl gets shy about loads and stores of the entire
> aggregate. Then I use a test case:
>
> ; ModuleID = 'test1.ll'
> define i32 @fun(i32* nocapture %X, i32 %i) nounwind uwtable readonly {
> %stackArray = alloca <4 x i32>
> %XC = bitcast i32* %X to <4 x i32>*
> %arrayVal = load <4 x i32>* %XC
> store
2012 Mar 10
0
[LLVMdev] scalarrepl fails to promote array of vector
On Mar 10, 2012, at 9:34 AM, Fan Dawei wrote:
> Hi all,
>
> I want to use scalarrepl pass to eliminate the allocation of mat_alloc which is of type [4 x <4 x float>] in the following program.
>
> $cat test.ll
>
> ; ModuleID = 'test.ll'
>
> define void @main(<4 x float>* %inArg, <4 x float>* %outArg, [4 x <4 x float>]* %constants)
2012 Feb 18
3
[LLVMdev] We need better hashing
On Fri, Feb 17, 2012 at 1:32 AM, Chris Lattner <clattner at apple.com> wrote:
> On Feb 17, 2012, at 12:26 AM, Talin wrote:
> > OK here's a patch with the latest, including unit tests. I've also tried
> to make the comments clear that this is intended for the case of "generic"
> key types, where you are either hashing multiple data types together, or
> you
2012 Feb 17
4
[LLVMdev] We need better hashing
OK here's a patch with the latest, including unit tests. I've also tried to
make the comments clear that this is intended for the case of "generic" key
types, where you are either hashing multiple data types together, or you
don't know in advance what the data type will be - for cases such as
strings where a tailored algorithm is available, you should use that
instead of
2012 Feb 17
0
[LLVMdev] We need better hashing
On Feb 17, 2012, at 12:26 AM, Talin wrote:
> OK here's a patch with the latest, including unit tests. I've also tried to make the comments clear that this is intended for the case of "generic" key types, where you are either hashing multiple data types together, or you don't know in advance what the data type will be - for cases such as strings where a tailored algorithm
2010 Feb 03
1
[LLVMdev] scalarrepl tuning
In svn r95224 I modified the scalar replacement (SROA) pass to use different criteria to decide when it is likely to be profitable to split up an aggregate into its separate elements. The commit message has a pretty decent explanation, but I wanted to give some further detail here. I am hoping that the llvm-dev list allows messages with attachments. If the graphs get stripped off, this
2012 Feb 18
0
[LLVMdev] We need better hashing
On Feb 18, 2012, at 1:11 AM, Talin wrote:
> + /// Add an ArrayRef of arbitrary data.
> + template<typename T>
> + GeneralHash& add(ArrayRef<T> ArrayVal) {
> + addBits(ArrayVal.begin(), ArrayVal.end());
> + return *this;
> + }
>
> Doesn't this have the same host-specificity problem, except that it will cause things that *are* stable to vary,
2011 Jul 01
2
[LLVMdev] How to prevent generation of wide integers in LLVM IR?
On 01.07.2011 12:03, Eli Friedman wrote:
> On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий
> <vasiliy.korchagin at gmail.com> wrote:
>> Hello, LLVMdev.
>>
>> The problem is that C backend doesn't support integers wider than 64
>> bits, but I need to use it on programs with wide integers in LLVM IR. My
>> question is how to deny LLVM to generate wide
2011 Jul 01
0
[LLVMdev] How to prevent generation of wide integers in LLVM IR?
On 1 July 2011 13:35, Vasiliy Korchagin <vasiliy.korchagin at gmail.com> wrote:
> On 01.07.2011 12:03, Eli Friedman wrote:
>> On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий
>> <vasiliy.korchagin at gmail.com> wrote:
>>> The problem is that C backend doesn't support integers wider than 64
>>> bits, but I need to use it on programs with wide
2012 Mar 07
2
[LLVMdev] Scalar replacement of arrays
Hi all,
I'm implementing a virtual processor which features dynamic register
indexing, and I'm struggling to make LLVM 3.0 produce good code for it.
The register set is implemented as an LLVM array so it can be
dynamically indexed using GEP. However, most of the time the virtual
processor's registers are just statically indexed, and so I
expected/hoped the code would be as
2011 Jun 19
2
[LLVMdev] Phase Interactions
Dear all,
I am doing few experiments to do understand optimization phase
interactions. Here is a brief description of my experiements.
1. I picked the list of machine independent optimizations acting on
llvm IR (those that are enabled at O3).
2. for each optimzation in the optimization-list
a) Compiled the program using 'clang -c O0 -flto program.c'
b) opt
2012 Mar 07
0
[LLVMdev] Scalar replacement of arrays
On Wed, Mar 7, 2012 at 12:47 PM, Nicolas Capens
<nicolas.capens at gmail.com> wrote:
> Hi all,
>
> I'm implementing a virtual processor which features dynamic register
> indexing, and I'm struggling to make LLVM 3.0 produce good code for it.
> The register set is implemented as an LLVM array so it can be
> dynamically indexed using GEP. However, most of the time the
2011 Jul 01
2
[LLVMdev] How to prevent generation of wide integers in LLVM IR?
Hello, LLVMdev.
The problem is that C backend doesn't support integers wider than 64
bits, but I need to use it on programs with wide integers in LLVM IR. My
question is how to deny LLVM to generate wide integer? Which part of
LLVM should I modify?
Best regards, V. Korchagin.
2008 Sep 22
0
[LLVMdev] Overzealous PromoteCastOfAllocation
On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote:
> Hi Dan,
>
>> Changing PromoteCastOfAllocation to not replace aggregate allocas
>> with
>> non-aggregate allocas if they have GEP users sounds reasonable to me.
> This sounds reasonable indeed, but still a bit arbitrary. Haven't
> figured out
> anything better yet, though.
>
>> Finding the
2011 Jul 01
0
[LLVMdev] How to prevent generation of wide integers in LLVM IR?
On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий
<vasiliy.korchagin at gmail.com> wrote:
> Hello, LLVMdev.
>
> The problem is that C backend doesn't support integers wider than 64
> bits, but I need to use it on programs with wide integers in LLVM IR. My
> question is how to deny LLVM to generate wide integer? Which part of
> LLVM should I modify?
scalarrepl is the
2011 Nov 02
5
[LLVMdev] About JIT by LLVM 2.9 or later
Hello guys,
Thanks for your help when you are busing.
I am working on an open source project. It supports shader language
and I want JIT feature, so LLVM is used.
But now I find the ABI & Calling Convention did not co-work with MSVC.
For example, following code I have:
struct float4 { float x, y, z, w; };
struct float4x4 { float4 x, y, z, w; };
float4 fetch_vs( float4x4* mat
2012 Mar 09
1
[LLVMdev] Scalar replacement of arrays
Nicolas Capens wrote:
> [...]
> I'm not sure if that's going to help achieve optimal code
> for when the array is sometimes being dynamically indexed.
> Essentially there should be some kind of store to load copy
> propagation. As far as I know that's exactly what mem2reg
> does, except that it only considers scalars and not elements
> of arrays.
>
> So would
2011 Jun 19
0
[LLVMdev] Phase Interactions
On 19 June 2011 14:44, Suresh Purini <suresh.purini at gmail.com> wrote:
> I am doing few experiments to do understand optimization phase
> interactions. Here is a brief description of my experiements.
>
> 1. I picked the list of machine independent optimizations acting on
> llvm IR (those that are enabled at O3).
> 2. for each optimzation in the optimization-list
>
2008 Sep 13
3
[LLVMdev] Overzealous PromoteCastOfAllocation
Hi Dan,
> Changing PromoteCastOfAllocation to not replace aggregate allocas with
> non-aggregate allocas if they have GEP users sounds reasonable to me.
This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out
anything better yet, though.
> Finding the maximum alignment is sometimes still useful though, so
> it would be nice to update the alignment field of