similar to: [LLVMdev] question about code in FixedLenDecoderEmitter.cpp

I spent some time playing with TableGen in order to improve the ability of backends to generate error messages with more precise source locations. The main requirement was to add a slot to the RecordVal class to hold the source location of the statement that defined the field. To make that easier to use, I added a third PrintFatalError() method that accepts a RecordVal and grabs the source

Jakob, I think this exactly what's happening. I debugged the resolveReferences for the ADD down into the resolve of TSFlags. It calls VarInit::getFieldInit for the "Val" field of "foo". The code is: Init *VarInit::getFieldInit(Record &R, const RecordVal *RV, const std::string &FieldName) const { if (isa<RecordRecTy>(getType()))

A question for all you TableGen aficionados: Does anyone know why the collection of RecordVal field values stored in a Record are represented by a SmallVector rather than some sort of map? This means that every time a record field is looked up by name, a linear search is performed. Is it a question of RAM usage?

Hi All, I have faced decoding conflict of DisassemblerTables from TableGen. I have instructions with same encoding and different mnemonic among different architecture versions. I have used Predicates and AssemblerPredicates to distinguish them on Codegen and Assembler but it does not work on Disassembler. When I look at TableGen/FixedLenDecoderEmitter.cpp, once there is decoding conflict,

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

Is anyone else seeing this bootstrap failure on current svn trunk? [ 6%] Linking CXX executable ../../bin/llvm-tblgen cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen && /sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt --verbose=1 /sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Werror=date-time

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After

Hello LLVM developers, Following some hints on this mailing list earlier this year on how to make clang faster than stock llvm.org builds I have implemented a script that builds a PGO optimized version of clang by following the guide here: http://llvm.org/docs/HowToBuildWithPGO.html This works great on macOS and Linux - we gained almost 15% in our project with this technique. I am now looking at

On Aug 20, 2012, at 9:22 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > Jakob, > > One more question. You had suggested 'ValueCols' as of type > list<list<string> >. Does the TableGen know how to extract it? It appears to > me that we may have to add support for that. You just start from getValueAsListInit() and go from there. /jakob

On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: > Thanks Aaron. > > I don't have a Windows system, and haven't seen any buildbot failures, so I > it's difficult to come up with a patch for something I can't reproduce > locally or see any actual failures. Could you send me the commands you used > that uncovered the failure? This

On Sat, Oct 14, 2017 at 11:38 AM, Don Hinton <hintonda at gmail.com> wrote: > Sorry, LLVM_FORCE_ENABLE_DUMP is the variable, which is used along with > LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. > > Again, I'm working on a fix, but could you also provide your cmake > command? Looks like we aren't handling your use case correctly. > > thanks.. > don >

On Sun, Oct 15, 2017 at 11:19 AM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:06 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: >> > Thanks Aaron. >> > >> > I don't have a Windows system, and haven't seen any

On Sat, Oct 14, 2017 at 4:22 PM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > The only way I could reproduce the problem you are seeing was to rerun > cmake with -DCMAKE_BUILD_TYPE=Debug in a build directory previously > configured with -DCMAKE_BUILD_TYPE=Release. I can fix that, but not sure > if it's what you are seeing. > > If this isn't your

On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link >> errors for me -- the only one I struggled with

Hi Jakob, Did you get a chance to look at the patch? Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jyotsna Verma Sent: Tuesday, August 28, 2012 1:01 PM To: 'Jakob Stoklund Olesen' Cc: llvmdev at

Jyotsna, I hadn't been following this, so I apologize if this has already been provided, but can you give a quick example of how this functionality is used? Thanks in advance, Hal On Tue, 28 Aug 2012 13:01:17 -0500 "Jyotsna Verma" <jverma at codeaurora.org> wrote: > Hi Jakob, > > Here is the first draft of the patch to add TableGen backend support > for the

Hi Hal, I will try to explain the functionality using a simple example. Let's say that we have three formats for 'ADD' instruction and we want to relate them. ADD - non-predicated form ADD_pt : predicate true ADD_pf : predicate false We can define the relationship between the non-predicated instructions and their predicate formats as follows: def getPredOpcode : InstrMapping { //

On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: >> [ brutal-snip ] >> ... >>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more >>>

On Jan 31, 2013, at 9:27 AM, Sean Silva <silvas at purdue.edu> wrote: > An extra call to resolveReferences after setting the value in the > `let` does fix this, but I'm not sure that it is the right fix. The > attached hackish patch seems to fix up a reduced version of the test > case you gave here (I haven't run a full battery of tests on it, so it > might cause