similar to: [X86] MoveImm flag for instructions

I am trying to categorize the machine instructions based on associated static (i.e., as encoded in .td file) machine description and the corresponding APIs. I would like to perform appropriate actions based on the kind of instruction in a tool that I am working on. For example, I'd like to distinguish between memop instructions involving immediate vs register. While it appears that I would be

That flag is specifically used by the foldImmediate optimization in the Peephole pass. We don't implement the TLI foldImmediate hook the peephole pass uses on x86 so we have no reason to set the flag on any instructions What are you trying to do? ~Craig On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I had

I think even if we did use it, MoveImmediate is intended for instructions that move an immediate into a register rather than into memory. It's supposed to indicate instructions that can be folded with the user of the register by changing the user to an immediate instruction. And it wouldn't be set on an instruction like "addl $0, %eax" or "addl $0, (%ecx)" either since

All, TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. It's possible to override this behavior by setting neverHasSideEffects = 1. It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more

On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. Hi Jakob, I don't understand what you're saying. Are you proposing that all properties (may load,

Doh. I missed the list in my first reply... Here's the replay of the conversation: ----- Renato: On 10 August 2015 at 14:05, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > --> %SP<def,tied1> = t2LDMIA_RET %SP<tied0>, pred:8, pred:%CPSR, > %R7<def>, %PC<def>, %SP<imp-use,undef>, %R7<imp-use,undef>, >

Hello, The function ARMBaseInstrInfo::AnalyzeBranch contains the following piece of code: } else if (I->isReturn()) { // Returns can't be analyzed, but we should run cleanup. CantAnalyze = !isPredicated(I); } else { This could lead to cases where for a block that ends with a conditional return, AnalyzeBranch returns false (i.e. analyzed), both TBB and FBB are

Hello, This bug affects all LLVM versions from 2.6 to trunk : http://llvm.org/bugs/show_bug.cgi?id=5081 The workaround I found is to add this : Index: lib/Target/X86/X86Instr64bit.td =================================================================== --- lib/Target/X86/X86Instr64bit.td (revision 105882) +++ lib/Target/X86/X86Instr64bit.td (working copy) @@ -1832,6 +1832,8 @@

Thanks for your reply, Paul. That seems to be a plausible explanation. I ended up adding code in my project to massage the output of llvm-config to the right paths based of the values of CMAKE_GENERATOR and build-mode. Bharadwaj On Dec 15, 2017 9:46 AM, "Robinson, Paul" <paul.robinson at sony.com> wrote: It may be that llvm-config simply doesn't understand a

On 9/24/2016 7:20 AM, Alex Bradbury wrote: > My concern is that all of the above adds yet more complexity to what > is already (in my view) a fairly difficult part of LLVM to understand. > The definition of MyRegisterClass is not so bad though, and perhaps it > doesn't matter how it works under the hood to the average backend > writer. I agree with the complexity, but I would

Hi Duncan, Thanks for your reply. I did try the method suggested by you. I got a foo.bc with -emit-llvm switch. llc on foo.bc gets me the same assertion failure, as you pointed out. Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and bugpoint-reduced-function.bc. My previous experience is that if I compile either if them, I would get the same failure as I did with foo.bc. That is

Hi, GlobalISel is fantastic, but obviously lacks a lot of the transforms that makes SelectionDAG so good. Whilst it's plenty usable, you'll find yourself wanting/needing to add a lot of manual little transforms to clean things up. I know of the RFC for a new Combiner with its own syntax (https://reviews.llvm.org/D54286 is the latest I can find of it), but after manually adding my Nth

On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > Hello, > > This bug affects all LLVM versions from 2.6 to trunk : > http://llvm.org/bugs/show_bug.cgi?id=5081 > > The workaround I found is to add this : > > Index: lib/Target/X86/X86Instr64bit.td > =================================================================== > --- lib/Target/X86/X86Instr64bit.td

Hi, I configured and built LLVM as follows on Mac OS 10.13.2: $ pwd <llvm-build-dir> $ cmake -G "Xcode" -DCMAKE_INSTALL_PREFIX=<llvm-install-dir> -DLLVM_ENABLE_PIC=0 <llvm-src-dir>/llvm $ xcodebuild -project LLVM.xcodeproj All binaries are in <llvm-build-dir>/Debug/bin. I am interested in using the output of llvm-config. Now, when I run $

On Mar 4, 2009, at 1:33 PM, S. Bharadwaj Yadavalli wrote: > Hi Duncan, > > Thanks for your reply. > > I did try the method suggested by you. I got a foo.bc with -emit- > llvm switch. llc on foo.bc gets me the same assertion failure, as > you pointed out. > > Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and > bugpoint-reduced-function.bc. My

I would like to generate the tags for LLVM sources to be used by emacs. I noticed that there is a tags target that can be specified to make to generate the tags file. It appears that the rules for this target are generated only with the specification of --with-tags option to configure script. However, I get the following errors respectively when I specify --with-tags or --with-tags=TAGS option to

Hi, Is there some place I can get instructions to load, build and debug LLVM and/or Clang using XCode on Mac OSX? Sorry if this is an FAQ - my (possibly quick) search did not yield an answer. Thanks, Bharadwaj

Hi, I notice that the following recent addition X86::CondCode X86::getCondFromBranch(const MachineInstr &MI) { switch (MI.getOpcode()) { default: return X86::COND_INVALID; case X86::JCC_1: return static_cast<X86::CondCode>( MI.getOperand(MI.getDesc().getNumOperands() - 1).getImm()); } } returns an invalid condition for JCC_2 and JCC_4 conditional opcodes. What is

Luke Dalessandro wrote: > S. Bharadwaj Yadavalli wrote: >> $ ../../../src/llvm-gcc-4.2/configure >> --prefix=<llvm-root>/install/x86_64-arm/llvm-gcc-4.2 >> --program-prefix=llvm-x86_64-arm >> --enable-llvm=<llvm-root>/install/x86_64-arm/llvm >> --enable-languages=c,c++ --disable-multilib >> --target=arm-unknown-linux-gnueabi > > I

I am trying to build a x86_64 to ARM cross compiler. I configured, built and installed LLVM as follows: $ ../../../src/llvm/configure --with-llvmgccdir=<llvm-root>/install/x86_64-arm/llvm-gcc-4.2 --enable-optimized --enable-jit --prefix=<llvm-root>/install/x86_64-arm/llvm --target=arm-unknown-linux-gnueabi $ make $ make install Then I configured gcc front end as follows: $