search for: x86asmparser

This fixes the failing x86_errors.s test. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff -ru test/lib/Target/X86/AsmParser/X86AsmParser.cpp llvm-toolchain-3.3-3.3/lib/Target/X86/AsmParser/X86AsmParser.cpp --- test/lib/Target/X86/AsmParser/X86AsmParser.cpp 2013-05-05 02:40:33.000000000 +0200 +++ llvm-toolchain-3.3-3.3/lib/Target/X86/AsmParser/X86AsmParser.cpp 2013-08-14 16:26:44.721547396 +0200 @@ -2382,8 +2382,10 @@ if (!WasOr...

On Sep 6, 2010, at 10:50 PM, David Shipman wrote: > Hi all, > > Just tried to build from svn sources with Visual Studio 2008, mostly > OK but fails > building the X86AsmParser lib - > > I see a few commits from yesterday that may have something to do with it, but no > idea what the solution is. Wow, that's a pretty terrible diagnostic. Does r113198 help? -Chris > > See MSVC's beautiful and concise output below; > > Compiling... > X86...

Hi all, Just tried to build from svn sources with Visual Studio 2008, mostly OK but fails building the X86AsmParser lib - I see a few commits from yesterday that may have something to do with it, but no idea what the solution is. -David See MSVC's beautiful and concise output below; Compiling... X86AsmParser.cpp C:\dev\MSVisualStudio\VC\include\xutility(313) : error C2664: 'bool `anonymous-namespace&...

...t; /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/tools/lli/Debug+Asserts/lli.o: In function `llvm::InitializeNativeTargetAsmParser()': > /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/llvm/include/llvm/Support/TargetSelect.h:149: undefined reference to `LLVMInitializeX86AsmParser' > collect2: ld returned 1 exit status I've been scratching my head trying to figure out why? I tried to look at llc's CMakeLists.txt and it seems very similar to lli's CMakeLists.txt file (both include asmparser in link components list). Any idea whats missing? TIA,...

...currently. Cc: Stephen Checkoway <s at pahtak.org> Cc: Tim Northover <t.p.northover at gmail.com> Cc: Jim Grosbach <grosbach at apple.com> Cc: Chris Lattner <sabre at nondot.org> Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> --- lib/Target/X86/AsmParser/X86AsmParser.cpp | 30 ++++++++++++++++++++++++++++++ test/MC/X86/x86-64.s | 7 +++++++ 2 files changed, 37 insertions(+) diff --git a/lib/Target/X86/AsmParser/X86AsmParser.cpp b/lib/Target/X86/AsmParser/X86AsmParser.cpp index 263eb5e..fba0f3c 100644 --- a/lib/Target/X86/AsmParser/X86AsmP...

...backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged, because it is dependent on r198584 which adds the X86AsmParser::is32BitMode() function. I don't think we would need to backport all of r198584, maybe just the function and the Mode32Bit SubtargetFeature. Could you take a look and let me know what you want to do? Thanks, Tom > Thanks, > Robert > > понедельник, 7 апреля 2014 г. пользователь...

...sabled, the feature appears to have regressed and it now crashes on all platforms: |mov eax, 1+++ // expected-error 2 {{unknown token in expression}}|| | |Assertion failed: (OperandStack.size() > 1 && "Too few operands."), function execute, file llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp, line 150.| Unfortunately an ASM parser test equivalent to the clang one never existed in LLVM's own suite. CC'ing in llvmdev. Does X86AsmParser.cpp have an active maintainer? Alp. > > > The log disabling the test in question was: > > Author: Chad Rosier <mcrosi...

...style=filled,color=olivedrab1]; ipa [shape=box,style=filled,color=olivedrab1]; X86Info [shape=box,style=filled,color=olivedrab1]; X86Disassembler [shape=box,style=filled,color=olivedrab1]; X86CodeGen [shape=box,style=filled,color=olivedrab1]; X86AsmPrinter [shape=box,style=filled,color=olivedrab1]; X86AsmParser [shape=box,style=filled,color=olivedrab1]; TransformUtils [shape=box,style=filled,color=olivedrab1]; Target [shape=box,style=filled,color=olivedrab1]; System [shape=box,style=filled,color=olivedrab1]; Support [shape=box,style=filled,color=olivedrab1]; SelectionDAG [shape=box,style=filled,color=oliv...

...:1:31: error: unknown token in expression >> > vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae} >> >> Unfortunately, I don’t think sae is supported yet. (I think the ^ is >> misplaced; it should point to the {rd-sae}.) >> >> (I may be wrong here but looks like even the X86AsmParser is lacking >> support for sae even though some instruction in the .td file contain {sae} >> in their asm syntax.) >> > > Oh it seems also the disasm support for sae is lacking: > > $ echo "62 f1 6c 1e 58 fc"|./Release+Asserts/bin/llvm-mc -disassemble > -tr...

Resending, any pointers are much appreciated. On 5/7/2012 11:16 PM, Ashok Nalkund wrote: > > > On 5/7/2012 10:17 PM, Bendersky, Eli wrote: > <snip> >>>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>>> have an asm parser for this

...not touched it in a few months. Last night I wiped my build tree to do a full rebuild with the latest version, and got the identical error as David Shipman was seeing last September. Are others able to build under VS9 right now? Thanks, John > Subject: Re: [LLVMdev] MS VS2008 build fails - X86AsmParser > From: Chris Lattner ("cla... at apple.com) > Date: Sep 6, 2010 11:11:46 pm > > On Sep 6, 2010, at 10:50 PM, David Shipman wrote: > > > Hi all, > > > > Just tried to build from svn sources with Visual Studio 2008, mostly > > OK but fails > > bu...

On 5/7/2012 10:17 PM, Bendersky, Eli wrote: <snip> >>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>> have an asm parser for this target >> >> I also tried other variations of the call with the same result: >>> $lli

...> > <stdin>:1:31: error: unknown token in expression > > vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae} > > Unfortunately, I don’t think sae is supported yet. (I think the ^ is > misplaced; it should point to the {rd-sae}.) > > (I may be wrong here but looks like even the X86AsmParser is lacking > support for sae even though some instruction in the .td file contain {sae} > in their asm syntax.) > Oh it seems also the disasm support for sae is lacking: $ echo "62 f1 6c 1e 58 fc"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text <stdin>...

...the generated X86GenAsmMatcher.inc. case 'f': // 1 string to match. if (memcmp(Name.data()+1, "lags", 4)) break; return 25; // "flags" So basically, what I'm seeing with "flags" (which should be a legit variable name) is that the X86AsmParser creates a reference to an implicit register instead of a reference to memory. There are additional issues here as well - what if we compile to SSE, but use a variable named "ZMM0" which is a register in AVX-512? Should this be allowed? We probably need some way to mark the registers (usi...

Hi, I am trying to assemble below instruction with latest LLVM code, but fail. Am I doing something wrong, or is this a bug? $ echo "vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}"|./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 -mcpu=knl -show-encoding -x86-asm-syntax=intel .text <stdin>:1:31: error: unknown token in expression vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}

...enabling MASM's convention that (unless specified) all memory location references should be RIP-relative. Without it, we emit the wrong instructions for "call", "jmp", etc., and anything we build fails at the linking stage. My best attempt at this so far is a small patch to X86AsmParser.cpp - just taking any Intel expression with no specified base register and switching it to use RIP - and this works alright. There's at least one exception: it breaks the "jcc" instructions, at least "jcc <label>". The issue seems to be that the "jcc" family...

...se 'f': // 1 string to match. > > if (memcmp(Name.data()+1, "lags", 4)) > > break; > > return 25; // "flags" > > > > So basically, what I’m seeing with “flags” (which should be a legit > variable name) is that the X86AsmParser creates a reference to an implicit > register instead of a reference to memory. > > There are additional issues here as well - what if we compile to SSE, but > use a variable named “ZMM0” which is a register in AVX-512? Should this be > allowed? > > > > We probably need s...

...() function in the generated X86GenAsmMatcher.inc. case 'f': // 1 string to match. if (memcmp(Name.data()+1, "lags", 4)) break; return 25; // "flags" So basically, what I’m seeing with “flags” (which should be a legit variable name) is that the X86AsmParser creates a reference to an implicit register instead of a reference to memory. There are additional issues here as well - what if we compile to SSE, but use a variable named “ZMM0” which is a register in AVX-512? Should this be allowed? We probably need some way to mark the registers (using attribu...

...t (unless specified) all memory location > references should be RIP-relative. Without it, we emit the wrong > instructions for "call", "jmp", etc., and anything we build fails at the > linking stage. > > > > My best attempt at this so far is a small patch to X86AsmParser.cpp - just > taking any Intel expression with no specified base register and switching > it to use RIP - and this works alright. There's at least one exception: it > breaks the "jcc" instructions, at least "jcc <label>". The issue seems to > be that the &qu...

...se 'f': // 1 string to match. > > if (memcmp(Name.data()+1, "lags", 4)) > > break; > > return 25; // "flags" > > > > So basically, what I’m seeing with “flags” (which should be a legit > variable name) is that the X86AsmParser creates a reference to an implicit > register instead of a reference to memory. > > There are additional issues here as well - what if we compile to SSE, but > use a variable named “ZMM0” which is a register in AVX-512? Should this be > allowed? > > > > We probably need s...