Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] Turning on LegalizeTypes by default"
2008 Oct 26
0
[LLVMdev] Turning on LegalizeTypes by default
On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote:
> Hi all, I plan to turn on the new type legalization infrastructure
> "LegalizeTypes" by default tomorrow. This is a redesign/
> reimplementation
> of the logic currently in LegalizeDAG that turns (for example) 64 bit
> arithmetic on a 32 bit machine into a series of 32 bit operations.
> As well
> as being a
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
Per subject, this patch adding an additional pass to handle vector
operations; the idea is that this allows removing the code from
LegalizeDAG that handles illegal types, which should be a significant
simplification. There are still some issues with this patch, but does
the approach look sane?
-Eli
-------------- next part --------------
Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp
2007 Feb 12
2
[LLVMdev] bitconvert for multi-typed RegisterClasses
Hi All,
I'm working on a back end for an architecture that makes use of multi-
typed register classes.
def MR: RegisterClass<"namespace", [type1, type2, ... ], ... >
When running some preliminary tests I found that the instruction
selector refused to select certain ops (specifically stores) for some
instructions when the operand type wasn't the first type for the
2009 May 22
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 9:14 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 5:26 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
>>
>>> Can you explain why you chose the approach of using a new pass?
>>>
>>> I pictured removing LegalizeDAG's type
2009 Nov 10
4
[LLVMdev] Altivec vs the type legalizer
PPC Altivec supports vector type v16i8 (and others) where the element
type is not legal (in llvm's implementation). When we have a
BUILD_VECTOR of these types with constant elements, LegalizeTypes
first promotes the element types to i32, then builds a constant pool
entry of type v16i32. This is wrong. I can fix it by truncating the
elements back to i8 in ExpandBUILD_VECTOR. Does
2008 Oct 28
0
[LLVMdev] Turning on LegalizeTypes by default
On Sun, Oct 26, 2008 at 2:03 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi all, I plan to turn on the new type legalization infrastructure
> "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation
> of the logic currently in LegalizeDAG that turns (for example) 64 bit
> arithmetic on a 32 bit machine into a series of 32 bit operations. As well
2007 Feb 12
0
[LLVMdev] bitconvert for multi-typed RegisterClasses
On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote:
>
> selector refused to select certain ops (specifically stores) for some
> instructions when the operand type wasn't the first type for the
> register class. After some digging around I seem to have solved the
> problem by creating bitconvert patterns between the types in the
> register class like the following:
>
>
2009 May 20
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> Per subject, this patch adding an additional pass to handle vector
> operations; the idea is that this allows removing the code from
> LegalizeDAG that handles illegal types, which should be a significant
> simplification. There are still some issues with this patch, but does
> the approach
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 Nov 10
1
[LLVMdev] Altivec vs the type legalizer
Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8
into v16i32, what should happen is that the return type of the BUILD_VECTOR
continues to be v16i8, but the type of the operands changes to i32, so you
end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8.
The target then has all the info it needs to produce the best code, but needs
to be careful
2013 Mar 05
4
[LLVMdev] Vector splitting vs widening
Hello,
Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example:
Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0]
Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0]
Split node result: 0x23469e0: v4f32 =
2016 Mar 17
2
generate vectorized code
On Wed, Mar 16, 2016 at 6:38 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> On Mar 16, 2016, at 5:38 PM, Rail Shafigulin <rail at esenciatech.com> wrote:
>
> On Wed, Mar 16, 2016 at 11:48 AM, Mehdi Amini <mehdi.amini at apple.com>
> wrote:
>
>> Hi Rail,
>>
>> Two hints to begin with:
>>
>> 1) Makes sure you example is
2016 Mar 18
3
generate vectorized code
On Thu, Mar 17, 2016 at 2:41 PM, Rail Shafigulin <rail at esenciatech.com>
wrote:
> On Thu, Mar 17, 2016 at 10:10 AM, Rail Shafigulin <rail at esenciatech.com>
> wrote:
>
>> On Wed, Mar 16, 2016 at 6:38 PM, Mehdi Amini <mehdi.amini at apple.com>
>> wrote:
>>
>>>
>>> On Mar 16, 2016, at 5:38 PM, Rail Shafigulin <rail at
2012 Mar 23
2
[LLVMdev] Fixing VAARG on PPC64
The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems
currently has a problem handling integer types smaller than 64 bits.
This is because the ABI specifies that these types are zero-extended to
64 bits on the stack and the default logic provided in LegalizeDAG does
not use that convention. Specifically, for these targets we have:
setOperationAction(ISD::VAARG, MVT::Other, Expand);
2009 Nov 10
0
[LLVMdev] Altivec vs the type legalizer
Hi Dale,
> PPC Altivec supports vector type v16i8 (and others) where the element
> type is not legal (in llvm's implementation). When we have a
> BUILD_VECTOR of these types with constant elements, LegalizeTypes first
> promotes the element types to i32, then builds a constant pool entry of
> type v16i32.
are you sure? I would expect it to build v4i32.
Ciao,
Duncan.
2009 Nov 10
1
[LLVMdev] Altivec vs the type legalizer
On Nov 9, 2009, at 6:33 PM, Duncan Sands wrote:
> Hi Dale,
>
>> PPC Altivec supports vector type v16i8 (and others) where the
>> element type is not legal (in llvm's implementation). When we have
>> a BUILD_VECTOR of these types with constant elements, LegalizeTypes
>> first promotes the element types to i32, then builds a constant
>> pool entry of
2016 Sep 27
2
SelectionDAG::LegalizeTypes is very slow in 3.1 version
In 3.1, the backend is very slow to legalize types.
Following is the code snippet which may be the culprit:
%Result.i.i.i97 = alloca i33, align 8
%Result.i.i.i96= alloca i33, align 8
%Result.i.i.i95 = alloca i33, align 8
%Result.i.i.i94 = alloca i33, align 8
%Result.i.i.i93 = alloca i33, align 8
%Result.i.i.i92= alloca i33, align 8
%Result.i.i.i91 = alloca i33, align 8
2009 Nov 10
0
[LLVMdev] Altivec vs the type legalizer
On Nov 9, 2009, at 6:11 PM, Dale Johannesen wrote:
> PPC Altivec supports vector type v16i8 (and others) where the element
> type is not legal (in llvm's implementation). When we have a
> BUILD_VECTOR of these types with constant elements, LegalizeTypes
> first promotes the element types to i32, then builds a constant pool
> entry of type v16i32. This is wrong. I can
2012 Mar 23
2
[LLVMdev] Fixing VAARG on PPC64
On Fri, 23 Mar 2012 09:50:12 +0100
Ivan Llopard <ivanllopard at gmail.com> wrote:
> Hi Finkel,
>
> Le 23/03/2012 05:50, Hal Finkel a écrit :
> > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems
> > currently has a problem handling integer types smaller than 64 bits.
> > This is because the ABI specifies that these types are
> > zero-extended