similar to: [LLVMdev] Load/Store issues: tablegen/customization?

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] Load/Store issues: tablegen/customization?"

2008 Nov 11
0
[LLVMdev] Load/Store issues: tablegen/customization?
On Nov 10, 2008, at 1:20 PM, Daniel M Gessel wrote: > I've been running into two issues with load/store handling: > > (1) is that tablegen doesn't seem to handle the two predicates that > get attached to my instructions. The first is the predicate in > TargetSelectionDAG.td, identifying a load node as, say, extloadi8. The > second is my identification of the load as
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 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
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
2010 Mar 12
0
[LLVMdev] [PATCH] Before/After IR Dumps
On Friday 12 March 2010 08:13:05 Kalle Raiskila wrote: > David Greene wrote: > > Here's a rework using PassManager as Chris suggested. Comments? > > Tried this second patch with the svn version 97812 (the one the patch is > made against), but it doesn't compile: > "llvm/include/llvm/Pass.h:127: Error: expected unqualified-id before "&" >
2020 Jul 13
2
[Beginner] Understanding Tablegen language
Hi, I am new to LLVM and I find TableGen language really cryptic. The reference manual to the language is not helpful either. I can look at the existing .td file and reverse engineer but I am looking for a detailed manual. Specifically, I have below questions: 1. What is a basic syntax for writing a dag? From the lang ref manual I can see that its something like operator followed by ArgList which
2010 Mar 12
2
[LLVMdev] [PATCH] Before/After IR Dumps
David Greene wrote: > Here's a rework using PassManager as Chris suggested. Comments? Tried this second patch with the svn version 97812 (the one the patch is made against), but it doesn't compile: "llvm/include/llvm/Pass.h:127: Error: expected unqualified-id before "&" token" Seems raw_ostream is forward declared but not defined (adding a missing #include
2010 Mar 14
3
[LLVMdev] [PATCH] Before/After IR Dumps
On Mar 12, 2010, at 8:10 AM, David Greene wrote: > On Friday 12 March 2010 08:13:05 Kalle Raiskila wrote: >> David Greene wrote: >>> Here's a rework using PassManager as Chris suggested. Comments? >> >> Tried this second patch with the svn version 97812 (the one the patch is >> made against), but it doesn't compile: >>
2019 Nov 20
4
Tablegen PAT limitation?
Hi, The full trace stack: Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824! [ 85%] Building X86GenEVEX2VEXTables.inc... &nbsp;#0 0x000000000081b9b5
2017 Aug 26
2
Unaligned atomic load/store
Hi, While working on the AVR target, I noticed a problem with alignment and the various atomic operations. AVR is an 8-bit platform, and all data is unaligned (or 8-bit aligned if you will). Here's a small piece of LLVM IR exhibiting this (emitted by the Rust compiler): target datalayout = "e-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8" target triple =
2019 Sep 27
2
Maybe a TableGen bug?
Hi, Here's llvm-tblgen -print-records message: def LOADbos { // Instruction ABCInst ABCInstMMEMrr field bits<32> Inst = { 0, 0, 0, 0, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; field bits<32> SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
2017 Sep 25
0
What should a truncating store do?
(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our
2017 Sep 15
2
What should a truncating store do?
They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon
2009 Dec 22
2
[LLVMdev] LegalizeDAG Error?
The LegalizeDAG.cpp file has this code in SelectionDAGLegalize::PromoteNode: case ISD::BSWAP: { unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, DAG.getConstant(DiffBits, TLI.getShiftAmountTy()));
2010 Mar 15
1
[LLVMdev] SelectionDAG constant folding leads to assertion failure
My experimental code calls DAG.getNode to construct a unary node with a flag result. Unfortunately the argument turns out to be constant, so lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2332 calls VT.getSizeInBits on the flag type, which isSimple(), so we call V.getSizeInBits at ValueTypes.h:560 and fail at ValueTypes.h:240: clang: .../include/llvm/CodeGen/ValueTypes.h:240: unsigned int
2015 May 12
2
[LLVMdev] i1 types in MergeConsecutiveStores
Hello LLVM, In DAGCombiner.cpp, MergeConsecutiveStores uses int64_t ElementSizeBytes = MemVT.getSizeInBits()/8; https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L10669 which is broken for i1 types where getSizeInBits() == 1. My out-of-tree target hits this case and eventually LLVM asserts in Type.cpp. Is there some reason MergeConsecutiveStores should
2010 May 14
7
[Bug 28107] New: [NV31]
https://bugs.freedesktop.org/show_bug.cgi?id=28107 Summary: [NV31] Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: finest.bug at
2017 Sep 25
3
What should a truncating store do?
On 9/25/2017 9:14 AM, Björn Pettersson A wrote: > > (Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to
2012 Jul 27
2
[LLVMdev] TLI.getSetCCResultType() and/or MVT broken by design?
I'm running into lots of problems with this call back. Mostly the problem occurs because this callback is used before types are legalized. However, the code generator does not have a 1-1 correspondence between all LLVM types and the codegen types. This leads to problems when getSetCCResultType is passed in an invalid type, but has a valid LLVM type attached to it. An example is <3 x
2018 Nov 27
3
[RFC] Tablegen-erated GlobalISel Combine Rules
Hi All, I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S),