similar to: [LLVMdev] tblgen and sign-extended constants too large for type

Allow me to rephrase my question: How much agony and gnashing of teeth will I cause if I commit this patch to tblgen (fully tested and changes to DAGISelEmitter.cpp also committed)? -scooter On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular > type? > > My case is an xor with i8 immediate where

My feeling is tblgen shouldn't make assumptions about whether the backend will treat the value as signed or unsigned (after all MVT::ValueType does not convey sign information). Perhaps it's cleaner to just check if it fits as unsigned? Chris? Evan On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular

Micah, One more thing ;) -- llvm::getEnumName in utils/TableGen/CodeGenTarget.cpp -Hal On Tue, 31 Jul 2012 21:02:02 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Ahh yep, thanks for catching that, new patch attached. > > > -----Original Message----- > > From: Hal Finkel [mailto:hfinkel at anl.gov] > > Sent: Tuesday, July 31, 2012 1:40 PM

On Thu, Dec 1, 2011 at 9:11 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > >> On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >>> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>>> For a bit of an experiment I've been trying to compile LLVM & Clang

On Dec 1, 2011, at 1:13 PM, David Blaikie wrote: >>> (there's also some legitimate unreachable code warnings I'd be happy >>> to fix as I find them, things like: >>> >>> --- a/lib/Support/CommandLine.cpp >>> +++ b/lib/Support/CommandLine.cpp >>> @@ -294,10 +294,7 @@ static inline bool ProvideOption(Option *Handler, >>>

On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >> For a bit of an experiment I've been trying to compile LLVM & Clang >> with -Weverything (disabling any errors that seem like more noise/less >> interesting). One warning I've recently hit a few instances of is >>

On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>> For a bit of an experiment I've been trying to compile LLVM & Clang >>> with -Weverything (disabling any errors that seem like more noise/less >>> interesting).

Ahh yep, thanks for catching that, new patch attached. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, July 31, 2012 1:40 PM > To: Villmow, Micah > Cc: Developers Mailing List > Subject: Re: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> > > Micah, > > I think that your patch is missing the necessary

Are multi-output patterns in TableGen supposed to work, or is that a known limitation in the current implementation? If I have TableGen code like the following... 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; 1244 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0,

Thanks for the info. Is this on someone's list of things to do? On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> > wrote: > > Are multi-output patterns in TableGen supposed to work, or is that a known > limitation in the current implementation? >

On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Are multi-output patterns in TableGen supposed to work, or is that a known limitation in the current implementation? It is a known limitation. You have to write C++ code to match patterns with multiple outputs. > > If I have TableGen code like the following... > > 1242 def SDTTestNode

It has been something we've talked about for years, but I'm not aware of anyone working on it right now. On Jan 6, 2013, at 5:34 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Thanks for the info. Is this on someone's list of things to do? > > > On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4,

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

Hi there, I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it. Observe: llvm[3]: Compiling Deserialize.cpp for Release build In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead er.h:18, from

The rgl package currently crashes R when running under Xvfb (the "virtual frame buffer" server), at least on MacOSX. It makes sense that it shouldn't be able to work there (it needs interactivity), but I don't know how to detect the problems before they cause the crash. Currently the error happens the first time you try to open an rgl window; when rgl calls XCreateWindow R

Hi Krzysztof, Today I try it on llvm9.0.0 version. &nbsp; def bos : RPPInstMMEMrr<OPC_STORE, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (outs), (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !strconcat(opcodestr, ""), "$rs1,

def STOREbos { // InstructionEncoding Instruction RPPInst RPPInstMMEMrr &nbsp; field bits<32&gt; Inst = { 0, 0, 0, 1, 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 }; &nbsp; field bits<32&gt; SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. 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: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!

On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: > For a bit of an experiment I've been trying to compile LLVM & Clang > with -Weverything (disabling any errors that seem like more noise/less > interesting). One warning I've recently hit a few instances of is > -Wweak-vtable which is, in fact, an explicitly documented LLVM coding > standard (

Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is it easy to post an example? At 11/18/2020 01:55 PM, Thomas Lively wrote: >Hi Paul, > >I think this would be time well spent. At least in the WebAssembly backend, the vast majority of our ISel work is still done with DAG ISel. I know this is different from the performance work you have in mind, but one of my