search for: aarch64isellow

...AArch64/AArch64AsmPrinter.cpp @@ -281,6 +281,8 @@ void AArch64AsmPrinter::EmitEndOfAsmFile(Module &M) { } Stubs.clear(); } + } else if (Subtarget->isTargetDarwin()) { + OutStreamer.EmitAssemblerFlag(MCAF_SubsectionsViaSymbols); } } diff --git a/lib/Target/AArch64/AArch64ISelLowering.cpp b/lib/Target/AArch64/AArch64ISelLowering.cpp index 48f34c0..0feaa0d 100644 --- a/lib/Target/AArch64/AArch64ISelLowering.cpp +++ b/lib/Target/AArch64/AArch64ISelLowering.cpp @@ -32,6 +32,8 @@ using namespace llvm; static TargetLoweringObjectFile *createTLOF(AArch64TargetMachine &TM) {...

...get's multiply instruction doesn't care (detect) overflow. I am wondering if I can always set the boolean to false. I am not sure about this as I see AArch64 [1] seems trying to emulate the overflow behavior. Thanks. [1] https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64ISelLowering.cpp ​Regards, chenwj​ -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180228/a45f4ba0/attachment.html>

Hey, I am working on a new back-end, in my back end, I require to pass every argument through a register when calling a function, unless the argument is part of the ellipsis (...) and then pass it through the stack, I've tried creating a CCCustom function to analyze the operands when a function has var args, however, the information whether the out val is fixed or not is not passed into the

Matt, Thanks for the response. Is there an example in the code somewhere of doing the intrinsic ID method? I don't need to put it a lot of places so I'm not sure it warrants adding a node. Thanks. On Tue, Feb 2, 2016 at 12:35 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Feb 2, 2016, at 09:29, Ryan Taylor via llvm-dev < > llvm-dev at lists.llvm.org>

...sn't care (detect) overflow. I am > wondering if I can always set the boolean to false. I am not sure about > this as I see AArch64 [1] seems trying to emulate the overflow behavior. > > Thanks. > > [1] https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/ > AArch64ISelLowering.cpp > > ​Regards, > chenwj​ > > -- > Wei-Ren Chen (陳韋任) > Homepage: https://people.cs.nctu.edu.tw/~chenwj > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/...

...ler/llvm_3_ 2/install/bin/clang++ You should run debug and retail builds too because the warnings can become serious if there is something used in a DEBUG that is only referenced there. llvm[3]: Compiling HexagonAsmPrinter.cpp for Debug+Asserts build /home/rkotler/llvm_trunk/lib/Target/AArch64/AArch64ISelLowering.cpp:4244:22: error: comparison of integers of different signs: 'int' and 'unsigned int' [-Werror,-Wsign-compare] assert((Lane < V1.getOperand(0).getValueType().getVectorNumElements()) ~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~...

...get's multiply instruction doesn't care (detect) overflow. I am wondering if I can always set the boolean to false. I am not sure about this as I see AArch64 [1] seems trying to emulate the overflow behavior. Thanks. [1] https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64ISelLowering.cpp ​Regards, chenwj​ -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-de...

...g++ > > > You should run debug and retail builds too because the warnings can become > serious if there is something used in a DEBUG that is only referenced there. > > llvm[3]: Compiling HexagonAsmPrinter.cpp for Debug+Asserts build > /home/rkotler/llvm_trunk/lib/Target/AArch64/AArch64ISelLowering.cpp:4244:22: > error: > comparison of integers of different signs: 'int' and 'unsigned int' > [-Werror,-Wsign-compare] > assert((Lane < > V1.getOperand(0).getValueType().getVectorNumElements()) > ~~~~ ^ > ~~~~~~~~~~~~~...

...t; You should run debug and retail builds too because the warnings can become >> serious if there is something used in a DEBUG that is only referenced there. >> >> llvm[3]: Compiling HexagonAsmPrinter.cpp for Debug+Asserts build >> /home/rkotler/llvm_trunk/lib/Target/AArch64/AArch64ISelLowering.cpp:4244:22: >> error: >> comparison of integers of different signs: 'int' and 'unsigned int' >> [-Werror,-Wsign-compare] >> assert((Lane < >> V1.getOperand(0).getValueType().getVectorNumElements()) >>...

...-dev > <llvm-dev at lists.llvm.org> wrote: > > Did anyone else come by such requirement? is there any other way anyone > could recommend handling such requirement? > > Apple's calling convention on iOS does this. We have two separate > CC_Whatever definitions and then AArch64ISelLowering.cpp chooses which > one to use based on whether the argument is fixed or not (see line > 3446 onwards). > > Cheers. > > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180808/...

...an example in the code somewhere of > doing the intrinsic ID method? I don't need to put it a lot of places so > I'm not sure it warrants adding a node. > > > > Thanks. > > Just do a git grep “getNode(ISD::INTRINSIC_WO_CHAIN”. It looks like there > are a bunch in AArch64ISelLowering -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/555b3dde/attachment.html>

...requested ResNo (which asserts when asked for ResNo == 1 and returning ResNo == 0) and returning a ISD::MERGE_VALUES without mutating the ResNo (which leads to constant folding merging the two result values together, effectively dropping the second one). The code I based this on is LowerXALUO in AArch64ISelLowering which returns a MERGE_VALUES without mutating the ResNo. I’m concerned that AArch64 may be dropping the carry bit based on the semantics observed above, but don’t know AArch64 well enough to verify. SDValue MyTarget::LowerXMUL_LOHI(SDValue Op, SelectionDAG &DAG) const { EVT VT = Op.g...

...PR64:$Rt, GPR64sp:$Rn, GPR32:$Rm, ro_Wextend64:$extend), []>; } def AArch64fakeload64 : SDNode<"AArch64ISD::FakeLoad64", SDTIntBinOp, [SDNPHasChain]>; def AArch64fakestore64 : SDNode<"AArch64ISD::FakeStore64", SDTIntBinOp, [SDNPHasChain]>; to AArch64ISD in AArch64ISelLowering.h below ISD::FIRST_TARGET_MEMORY_OPCODE: FakeLoad64, FakeStore64 in AArch64SelectionDAGInfo::EmitTargetCodeForMemcpy(): SmallVector<SDValue, 4> Ops; Ops.push_back(Chain); Ops.push_back(DAG.getNode(ISD::ADD, dl, MVT::i64, Src, DAG.getConstant(SrcOf...

Hi, When using Wine to run Windows ARM64 executables on Linux, there's one major ABI incompatibility between the two; Windows treats the x18 register as the reserved platform register, while it is free to be clobbered anywhere in code on Linux. The Wine code sets up this register before passing control over to the Windows executable code, but whenever the Windows code calls a function

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI

...know the backend will place it on the stack, as demanded by the calling convention). ARM will also coerce structures below a certain size, however the call lowering code in ARMISelLowering still has logic to split a byval aggregate between the stack and registers (why not I have to say looking at AArch64ISelLowering and the clang code it's not immediately obvious to me where aggregates get split between the stack and registers (which is quite clear in MipsTargetLowering::passByValArg). What am I missing here? It seems to me there are a few possibilities for targets where the ABI indicates aggregates...

I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This question came about through reviewing work from Leslie Zhai on GlobalISel > support for RISC-V, which also motivated me to revisit code which I've always > felt was a

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,