similar to: Mips unconditionally uses fast-isel?

> > I was mucking around in FastISel, and was surprised to see the test > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > failed. This was surprising because it specifies -fast-isel=false. > > > > Does the Mips code generator use fast-isel even when you ask it not to? > > Thanks, > > --paulr > > This seems to be an all-targets bug.

> > > > I was mucking around in FastISel, and was surprised to see the test > > > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > > > failed. This was surprising because it specifies -fast-isel=false. > > > > > > > > Does the Mips code generator use fast-isel even when you ask it not > to? > > > > Thanks,

Well, 'optnone' is already not identical to -O0, and given the nature of things, probably can't be; but I am persuaded that it's reasonable for it to honor the -fast-isel option as a debugging tactic. I'll take an AI to make this happen. Thanks, --paulr P.S. One nit, the "O0 + optnone" case should not have an asterisk, the FastISel flag is not manipulated if the opt

> > The other thing that might work, is having TargetMachine remember how > > the fast-isel option got set, and make OptLevelChanger do the right > > thing. But that seems like a hack to work around Mips not obeying the > > specified optimization level, honestly. > > I think we should do that as well. I don't think it's right that optnone > enables Fast

The driving goal of 'optnone' is to have an easy way for programmers to get an "-O0 like" debugging experience for selected functions, without making them build everything with –O0. To that end, we turn off as much optimization as we reasonably can, but in the context of a pipeline that is generally expecting optimizations to be enabled, in practice we can't exactly match –O0

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

Fast-isel is not equipped in general to deal with non legal types. It would seem that an llvm assembler pass run after clang but before llvm could do the lowering though. Any thoughts? Reed

I understand that but falling back makes the compilation slower. I'm wondering what could be done to remove this restriction about fast-isel not being able to handle non legal types. ________________________________________ From: Anton Korobeynikov [anton at korobeynikov.info] Sent: Sunday, August 31, 2014 12:55 AM To: Reed Kotler Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] lowering

On Mon, Apr 4, 2011 at 9:50 PM, Eric Christopher <echristo at apple.com> wrote: > > On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote: > >> [...] Although most optimizations are turned off >> already and the FastISel instruction selector is used, the "fast" path >> for first-time code generation is still the bottleneck [...] > > This is effectively

On Apr 5, 2011, at 2:56 AM, Viktor Pavlu wrote: > On Mon, Apr 4, 2011 at 9:50 PM, Eric Christopher <echristo at apple.com> wrote: >> >> On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote: >> >>> [...] Although most optimizations are turned off >>> already and the FastISel instruction selector is used, the "fast" path >>> for first-time

On Tue, 18 Dec 2018 at 07:11, Gleb Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > However, I haven't managed to get a "Constant<>" in the DAG when compiling for X86. I'm interested in how it is lowered. Can you please give me some guidance on this? How are you looking? When I run "llc -mtriple=x86_64-linux-gnu -debug-only=isel" on your IR I get

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

Jim Grosbach <grosbach at apple.com> writes: >> To me, increasing coverage of the FastISel seemed more involved than >> directly emitting opcodes to memory, with a lesser outlook on >> reducing overhead. > > That seems extremely unlikely. You'd be effectively re-implementing > both fast-isel and the MC binary emitter layers, and it sounds like a > new

On Mon, Jul 11, 2011 at 2:44 PM, Eric Christopher <echristo at apple.com> wrote: > > On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: > >> I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes

Hi, I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. Vector legalization that comes afterwards just scalarized the

For ARM targets on linux, revision 183966 made Fast ISel default. Unfortunately, Fast ISel is broken in terms of applying the ARMII::MO_PLT flags to calls in PIC mode (at least when emitting assembly); it never does this. The normal ISel pass handles this situation correctly so a temporary local change to disable FastISel for linux / NaCl targets is working for me right now. I'm not very

Hi, LLVM, I found LLVM codegen has 3 passes for instruction scheduling: 1) pre-ra sched 2) post-ra sched 3) mi sched. for RISC machines, there are data hazard cases appear only after Register Allocation(RA). for example, $t0 is used immediately after writing(RAW): ld $t0, MEM add $t2, $t0, $0 There may be one or more stall in pipeline. Instruction scheduler can detect this kinds of conflict

Cool, I'll file a bug tomorrow at work and add you to the CC list. Thanks! Gordon Keiser Software Development Engineer Arxan Technologies gkeiser at arxan.com www.arxan.com  Protecting the App EconomyT  > -----Original Message----- > From: Eric Christopher [mailto:echristo at gmail.com] > Sent: Tuesday, August 20, 2013 9:47 PM > To: Gordon Keiser > Cc: llvmdev at