Displaying 20 results from an estimated 1000 matches similar to: "Backend subtraction changed to negative addition"
2015 Oct 22
2
add intrinsic function support for customized backend
Hi, All,
I want to add one intrinsic function for my particular backend. Let's say
the intrinsic function is named "foo" which takes two i32 inputs and has
one i32 output.
First, I add this line "def int_foo : Intrinsic<[llvm_i32_ty],
[llvm_i32_ty, llvm_i32_ty], [IntrReadArgMem]>;" in
/include/llvm/IR/Intrinsics.td.
Then, in my target/InstrInfo.td, I'm supposed
2015 Oct 22
2
add intrinsic function support for customized backend
Hi, Gaƫl,
Thanks for your detailed reply. I tried the pattern matching first,
however, the intrinsic function is matching with a normal function call.
For example, I have the following IR, which contains intrinsic function
"foo":
*****************************************************************************************
*define i32 @test_func() {*
*EntryBlock:*
* %0 = call i32
2013 Mar 25
1
[LLVMdev] Backend port: Adding negative immediates
Hi,
I'm doing a backend port and I'm having trouble with adds that have
negative immediates.
My architecture only has instructions for subtracting and adding 8bit
immediate values (they will be zero-extended, thus unsigned).
Bigger immediates have to be moved in a register first.
The problem is:
Expressions like "b - 1" result in "add nsw i32 %b, -1" in LLVM IR.
They
2009 Mar 31
0
[LLVMdev] adjust address calculus for an architecture that does not address bytes
Christian Sayer wrote:
> Hi,
> my target architecture has a kind of "16bit addressing mode", i.e. one address does not address 8 bit but a 16bit chunk. Consequently, every constant used to calculate effective addresses must be divided by two.
> So far this is not such a problem for stack objects since FrameIndexes, function arguments etc. have a lot of custom lowering code where
2015 Nov 25
2
need help for customized backend LowerFormalArguments
Hi, All,
I'm trying to build a customized backend and I need to lower the formal
arguments like this:
There are several specific registers just for storing formal arguments. And
also there are several general purpose registers for computation. If there
is an instruction which uses parameters, I should first use a move
instruction, which moves the value to general purpose register. For
2010 Sep 04
6
[LLVMdev] Possible missed optimization?
Hello, while testing trivial functions in my backend i noticed a suboptimal
way of assigning regs that had the following pattern, consider the following
function:
typedef unsigned short t;
t foo(t a, t b)
{
t a4 = b^a^18;
return a4;
}
Argument "a" is passed in R15:R14 and argument "b" is passed in R13:R12, the
return value is stored in R15:R14.
Producing the
2010 Sep 04
0
[LLVMdev] Possible missed optimization?
Hello
> and as the return value. Is this a missed optimization from LLVM or did i
> miss something out?
> Changing the register allocation order didnt work.
What are the patterns for xor / mov ?
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
2009 Mar 31
2
[LLVMdev] adjust address calculus for an architecture that does not address bytes
Hi,
my target architecture has a kind of "16bit addressing mode", i.e. one address does not address 8 bit but a 16bit chunk. Consequently, every constant used to calculate effective addresses must be divided by two.
So far this is not such a problem for stack objects since FrameIndexes, function arguments etc. have a lot of custom lowering code where this can be done.
But when it comes
2009 Apr 01
2
[LLVMdev] adjust address calculus for an architecture that does not address bytes
> > At first I thought this could be handled when lowering
> loads and stores, but I realize that I can only catch the
> targeted addresses of loads/stores here - however address
> calculation nodes may occur anywhere in a DAG.
> >
> > So my first impulse would be to adjust the constants when
> the GEP instructions are transformed to ADDs. Afaics his
> would mean
2013 Mar 21
9
[LLVMdev] Simpler types in TableGen isel patterns
Currently, instruction selection patterns are defined like this:
def : Pat<(and (not GR32:$src1), GR32:$src2),
(ANDN32rr GR32:$src1, GR32:$src2)>;
def : Pat<(and (not GR64:$src1), GR64:$src2),
(ANDN64rr GR64:$src1, GR64:$src2)>;
TableGen infers the types of $src1 and $src2 from the specified register classes, and that is the only purpose of the register
2014 Dec 26
2
[LLVMdev] X86 disassembler & assembler mismatch
hi,
some instructions mismatch between assembler & disassembler, like below.
it seems this happens with all SSECC related instructions?
thanks,
Jun
$ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble
-triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding
.text
cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17]
$
2009 Mar 24
2
[LLVMdev] Reducing .td redundancy
Is it legal to do something like a !strconcat on a non-string entity? That
is, is there some operation that will let me do this (replace SOME_CONCAT with
an appropriate operator):
(WARNING! Hacked-up tablegen ahead!)
multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr,
SDNode OpNode> {
// Vector operation emulating scalar (fp)
2014 Dec 26
2
[LLVMdev] X86 disassembler & assembler mismatch
The IMM3/IMM5 come from here
X86RecognizableInstr.cpp
943 TYPE("SSECC", TYPE_IMM3)
944: TYPE("AVXCC", TYPE_IMM5)
On Thu, Dec 25, 2014 at 8:22 PM, Jun Koi <junkoi2004 at gmail.com> wrote:
>
>
> On Fri, Dec 26, 2014 at 11:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote:
>
>> hi,
>>
>> some instructions
2020 May 12
2
BPF tablegen+codegen question
In BPF, an ADD instruction is defined as a 2 register instruction:
0x0f. add dst, src. dst += src
In BPFInstrInfo.td this kind of ALU instruction is defined with:
def _rr : ALU_RR<BPF_ALU64, Opc,
(outs GPR:$dst),
(ins GPR:$src2, GPR:$src),
"$dst "#OpcodeStr#" $src",
[(set
2011 Sep 22
3
[LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits
Hi Bruno,
> Some comments:
>
> + // Try to synthesize horizontal adds from adds of shuffles.
> + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) ||
> + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&&
> + isHorizontalBinOp(LHS, RHS, true))
>
> 1) You probably want to do something like:
>
2012 Nov 16
2
[LLVMdev] Operand order in dag pattern matching in td files
Hi,
I have a simple question w.r.t the order of operands used in dag
pattern matching in target files. Some of them seem intuitive. But I
want to get it clarified anyway. I am using a pattern from
X86InstrFMA.td in the below example. Consider FMA3 pattern
(simplified).
let Constraints = "$src1 = $dst" in {
multiclass fma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand
2013 Mar 21
0
[LLVMdev] Simpler types in TableGen isel patterns
----- Original Message -----
> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> To: llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu
> Sent: Thursday, March 21, 2013 1:26:25 PM
> Subject: [LLVMdev] Simpler types in TableGen isel patterns
>
> Currently, instruction selection patterns are defined like this:
>
2017 Jul 11
2
error: In anonymous_4820: Unrecognized node 'VRR128'!
Thank You.
But can we use same register class for fadd as well,
is this instruction correct?
def VFADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1,
VRR128:$src2),"VFADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set
VRR128:$dst, (fadd VRR128:$src1, VRR128:$src2))]>, TA;
On Tue, Jul 11, 2017 at 9:00 PM, Craig Topper <craig.topper at gmail.com>
wrote:
>
2016 Mar 30
2
Instruction selection pattern for intrinsic returning llvm_any_ty
Hi,
On my out-of-tree target I have an intrinsic
def int_phx_divm_u16 : Intrinsic<[llvm_any_ty],
[llvm_i16_ty, llvm_i16_ty],
[IntrNoMem]>;
that I want to translate to the following instruction during instruction
selection:
def divm16_pseudo : MyPseudoInst<
(outs aNh_0_7:$dst, aNh_0_7:$dst2),
(ins
2011 Oct 06
4
[LLVMdev] Enhancing TableGen
On Oct 6, 2011, at 7:59 AM, David A. Greene wrote:
> For example, I want to be able to do this:
>
> defm MOVH :
> vs1x_fps_binary_vv_node_rmonly<
> 0x16, "movh", undef, 0,
> // rr
> [(undef)],
> // rm
> [(set DSTREGCLASS:$dst,
> (DSTTYPE (movlhps SRCREGCLASS:$src1,
>