Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Custom load/store code: determining offset or alignment"
2008 Sep 18
2
[LLVMdev] store addrspace qualifier
Mon Ping,
Thanks for the tip, but I can't for the life of me seem to get the
Value from a StoreSDNode. From looking at the SelectionDAGNodes header
file, the only class that has the getValue function call is
SrcValueSDNode that returns a Value type. The only class that has
getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode
is what I want and when I try to cast the
2017 Oct 23
2
EnableFastISel
Hi,
In SelectionDAGISel::SelectAllBasicBlocks
if (TM.Options.EnableFastISel)
FastIS = TLI->createFastISel(*FuncInfo, LibInfo);
followed by
if (!FastIS) {
LowerArguments(Fn);
} else {
The above implies that implementing FastIS is optional.
In contrast to that, testing whether FastIS is actually been used is
done by testing if TM.Options.EnableFastISel is set.
For example
2013 Mar 04
1
[LLVMdev] Custom Lowering of ARM zero-extending loads
Hi,
For my research, I need to reshape the current ARM backend to support
armv2a. Zero-extend half word load (ldrh) is not supported by armv2a, so I
need to make the code generation to not generate ldrh instructions. I want
to replace all those instances with a 32-bit load (ldr) and then and the
result with 0xffff to mask out the upper bits.
These are the modifications that I have made to
2017 Jul 29
2
ISelDAGToDAG breaks node ordering
Hi,
During instruction selection, I have the following code for certain LOAD
instructions:
const LoadSDNode *LD = cast<LoadSDNode>(N);
SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT,
PtrVT, MVT::Other,
LD->getBasePtr(), LD->getChain());
// Honestly, I have no idea what this does, but other memory
// accessing instructions
2010 Feb 10
2
[LLVMdev] Metadata
On Feb 10, 2010, at 10:20 AM, David Greene wrote:
> On Wednesday 10 February 2010 11:46:25 Chris Lattner wrote:
>
>>> There is not any mechanism to attach metadata with SDNode or
>>> MachineInstrs today.
>>
>> For nontemporal stores, you wouldn't want to do this anyway. In
>> selectiondag builder, you'd want to check the store instruction to
2010 Feb 10
3
[LLVMdev] Metadata
On Feb 10, 2010, at 12:42 PM, David Greene wrote:
> On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote:
>
>> I think that adding a bit to LoadSDNode and StoreSDNode would make sense.
>
> Ok. The consequence is that a number of functions will have to change to
> propagate this bit, analogous to what happens with isVolatile. It's
> essentially what we do
2013 Feb 19
9
[LLVMdev] [RFC] Add Intel TSX HLE Support
Hi All,
I'd like to add HLE support in LLVM/clang consistent to GCC's style [1].
HLE from Intel TSX [2] is legacy compatible instruction set extension to
specify transactional region by adding XACQUIRE and XRELEASE prefixes.
To support that, GCC chooses the approach by extending the memory order
flag in __atomic_* builtins with target-specific memory model in high
bits (bit 31-16 for
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
Here is the patch 0004-Enable-HLE-code-generation.patch
Yours
- Michael
On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote:
> Hi All,
>
> I'd like to add HLE support in LLVM/clang consistent to GCC's style [1].
> HLE from Intel TSX [2] is legacy compatible instruction set extension to
> specify transactional region by adding XACQUIRE and XRELEASE prefixes.
> To
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
Here is the patch 0002-Add-HLE-target-feature.patch
Yours
- Michael
On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote:
> Hi All,
>
> I'd like to add HLE support in LLVM/clang consistent to GCC's style [1].
> HLE from Intel TSX [2] is legacy compatible instruction set extension to
> specify transactional region by adding XACQUIRE and XRELEASE prefixes.
> To support
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
Here is the patch
0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch
Yours
- Michael
On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote:
> Hi All,
>
> I'd like to add HLE support in LLVM/clang consistent to GCC's style [1].
> HLE from Intel TSX [2] is legacy compatible instruction set extension to
> specify transactional region by adding XACQUIRE and
2017 Jul 31
0
ISelDAGToDAG breaks node ordering
On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote:
> Hi,
>
> During instruction selection, I have the following code for certain
> LOAD instructions:
>
> const LoadSDNode *LD = cast<LoadSDNode>(N);
> SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N),
> VT, PtrVT, MVT::Other,
> LD->getBasePtr(), LD->getChain());
>
2013 Feb 19
2
[LLVMdev] [RFC] Add Intel TSX HLE Support
Hi All,
I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to
specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order
flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
Hi Michael,
Why do you want to add transactional memory support to LLVM ? Can't you implement transactional memory using a library call ? Judging by the number of patches it looks like a major change to LLVM, and I am not sure that I understand the motivation for including it in LLVM.
Thanks,
Nadav
On Feb 19, 2013, at 11:52 AM, Michael Liao <michael.liao at intel.com> wrote:
2010 Feb 10
0
[LLVMdev] Metadata
On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote:
> I think that adding a bit to LoadSDNode and StoreSDNode would make sense.
Ok. The consequence is that a number of functions will have to change to
propagate this bit, analogous to what happens with isVolatile. It's
essentially what we do right now here. If everyone's ok with that, I'll go
that route.
2010 Feb 11
0
[LLVMdev] Metadata
On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote:
> On Feb 10, 2010, at 12:42 PM, David Greene wrote:
> > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote:
> >> I think that adding a bit to LoadSDNode and StoreSDNode would make
> >> sense.
> >
> > Ok. The consequence is that a number of functions will have to change to
> > propagate
2008 Sep 17
0
[LLVMdev] store addrspace qualifier
The address qualifier is stored in the type of %result. From that
operand, you can get the Value and then call getType. The type for
result should be a PointerType which you cast to a PointerType and
get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace()
-- Mon Ping
On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote:
> How do I access the address qualifier
2006 Dec 19
3
[LLVMdev] alias-aware scheduling
Hello,
I did a little experiment modifying LLVM to be able to use alias-analysis
information in scheduling so that independent memory operations may be
reordered.
Attached is a patch which implements this. I copied some routines from
DAGCombiner.cpp for using SDOperands with alias queries; it should
probably be factored out somewhere so the code can be shared. I
reorganized
2008 Sep 17
2
[LLVMdev] store addrspace qualifier
How do I access the address qualifier from the store instruction.
Given the following code:
define void @test_unary_op_anegate(float %x, float addrspace(11)*
%result) nounwind {
entry:
%neg = sub float -0.000000e+000, %x ; <float>
[#uses=1]
store float %neg, float addrspace(11)* %result
ret void
}
When I attempt to generate this code, I'm
2017 May 30
1
Pseudo-instruction that overwrites its input register
The reason the ones in PPCInstrInfo.td don't have the patterns to match is
the reason they are more analogous to your problem. Namely, tblgen does not
have a way to produce nodes with more than one result. The load-with-update
instructions do exactly that - one of the inputs is also an output, but the
other output is independent (and necessarily a separate register). The FMA
variants have
2016 Mar 28
0
RFC: atomic operations on SI+
On Fri, Mar 25, 2016 at 02:22:11PM -0400, Jan Vesely wrote:
> Hi Tom, Matt,
>
> I'm working on a project that needs few coherent atomic operations (HSA
> mode: load, store, compare-and-swap) for std::atomic_uint in HCC.
>
> the attached patch implements atomic compare and swap for SI+
> (untested). I tried to stay within what was available, but there are
> few issues