search for: fastisel

> > 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

...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 level is already zero. Does not affect the strength of your argument, of course. From: Daniel Sanders [mailto:Daniel.Sanders at imgtec.com] Sent: Wednesday, November 18, 2015 2:19 AM To: Robinson, Paul; llvm-dev at lists.llvm.org Subject: RE: Mips unconditionally...

...can't exactly match –O0 because "things break" if we turn off everything. Luckily, exactly matching –O0 isn't a requirement. Contemplating the "things break" situation, I am entirely willing to believe (it may have actually happened) that problems can occur when using FastISel in a pipeline that isn't expecting it. So, for purposes of diagnosing these 'optnone' problems, it seems useful to be able to force 'optnone' not to use FastISel. This is a different motivation than Daniel expressed, which is a more principled idea coming from the "optnon...

I'm still working on SSP support in LLVM. We have code that is in an IR pass StackProtector, SelectionDAG, FastISel, and some MachineFunction passes. Even in SelectiondDAG we have different code paths. I wonder if we can at least have only two code paths, one for SelectionDAG and the other for FastISel. IR pass may generate two forms of IR: 1) Almost pure IR, which contains only llvm.stackprotector that can be...

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 what fastisel was created for - there are just IR > constructs that don't go through that path. The idea is that fastisel > will get...

...enato Golin <renato.golin at linaro.org>wrote: > On 31 March 2014 20:55, Tim Northover <t.p.northover at gmail.com> wrote: > > I'd almost prefer to leave it in for the bugs to be discovered > > (perhaps after some simple tests of our own). ARM went wirthout > > FastISel support on Linux for years simply because it was declared > > Darwin-only. > > Given the unique opportunity we have now, I'd say we should at least > give it a try. > I'm not sure I understand what you're proposing: check in with FastISel turned on for Linux, or off?...

On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote: > I currently work on generating fast cycle-accurate simulators[2]. For > this, our institute has implemented a two-part adaptive compilation > scheme using the LLVM-JIT. 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 of the > simulators. This is for the largest part due to the SelectionDAG > instruction selection process, hence the motivation for a simpler, > two-pass code generator. Thi...

..., 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 code generation is still the bottleneck [...] >> >> This is effectively what fastisel was created for - there are just IR >> constructs that don't go through that path. The idea is that fastis...

...some follow-up patches) the PowerPC back end was changed to use types instead of register classes in instruction patterns. This matched similar changes that Jakob made for Sparc in r177835. I've recently come across an unpleasant side-effect of this change. I started looking at implementing FastISel for PPC64, and discovered that practically all of our patterns were rejected when looking for simple patterns eligible for FastEmit_*. Stepping through the tablegen code showed that we were rejecting them precisely because the patterns now contain value types instead of register classes (FastISelE...

...changed to use > > types instead of register classes in instruction patterns. This matched > > similar changes that Jakob made for Sparc in r177835. > > > > I've recently come across an unpleasant side-effect of this change. I > > started looking at implementing FastISel for PPC64, and discovered that > > practically all of our patterns were rejected when looking for simple > > patterns eligible for FastEmit_*. Stepping through the tablegen code > > showed that we were rejecting them precisely because the patterns now > > contain value type...

...the PowerPC back end was changed to use > types instead of register classes in instruction patterns. This matched > similar changes that Jakob made for Sparc in r177835. > > I've recently come across an unpleasant side-effect of this change. I > started looking at implementing FastISel for PPC64, and discovered that > practically all of our patterns were rejected when looking for simple > patterns eligible for FastEmit_*. Stepping through the tablegen code > showed that we were rejecting them precisely because the patterns now > contain value types instead of registe...

...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 familiar with the ISel passes. I'm guessing the correct > > thing to do here would be to apply the attribute correctly in FastISel > > so it works, but I'm k...

...inux, 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 familiar with the ISel passes. I'm guessing the correct thing to do here would be to apply the attribute correctly in FastISel so it works, but I'm kind of unfamiliar with this part of the code and won't have time...

...>> >> Does anyone have any ideas what we could do that doesn't add to the compile time? > > This seems odd. I'd think that fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block. I'm not entirely sure why, but FastISel does intentionally materialize constants at the beginning of the block. See FastISel::enterLocalValueArea etc. Maybe Dan knows why? -Eli

LGTM On Wed, Aug 21, 2013 at 1:51 PM, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > Hi, > > I have created a workaround to deal with the PIC function call. With this > patch, the FastISel will switch back to DAG lowering mechanism if (1) there > is a function call in the basic block and (2) the relocation model is PIC. > Please have a look. Hoping the patch will help. > > Sincerely, > Logan > > > On Wed, Aug 21, 2013 at 10:17 AM, Gordon Keiser <gkeiser at...

...trlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^ strlen1.c:12:3: note: include the header <stdio.h> or explicitly provide a declaration for 'printf' FastISel missed call: %call = call i64 @strlen(i8* %0) #3 1 warning generated. #include <string.h> char *hello = "hello"; int len; void foo() { len = strlen(hello); } int main() { foo(); printf("%i\n", len); }

I tried out CommentFlag and it looks ideal for this purpose. The attached patch adds a FastISel flag and prints it in the AsmPrinter and the IR dump. You can then call MachineInstr::setAsmPrinterFlag(MachineInstr::FastISel) to set the flag. Some passes seem to be stripping the comment flags though. The one I noticed is the pseudo-instruction expansion pass: # *** IR Dump After Machine Copy...

Hi Anton and JF, Thanks for your review. After reading the source code more carefully, I have come up with a different way fix this issue. We can simply resolve this issue by adding ARMII::MO_PLT flags with MachineInstrBuilder in FastISel pass (without failing back to DAG lowering). The new patch is attached, and the test case is not changed. Sorry for your inconvenience. Please have a look. Thanks for your help. Sincerely, Logan On Wed, Aug 21, 2013 at 10:52 PM, JF Bastien <jfb at google.com> wrote: > lgtm > &...

...;> >>> On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: >>> >>> This seems odd. I'd think that fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block. >> >> I'm not entirely sure why, but FastISel does intentionally materialize >> constants at the beginning of the block. See >> FastISel::enterLocalValueArea etc. Maybe Dan knows why? > > > Going bottom-up, FastISel doesn't know when it'll see the first use of a value > in a block. Cleverer schemes are possi...

Hi, I have created a workaround to deal with the PIC function call. With this patch, the FastISel will switch back to DAG lowering mechanism if (1) there is a function call in the basic block and (2) the relocation model is PIC. Please have a look. Hoping the patch will help. Sincerely, Logan On Wed, Aug 21, 2013 at 10:17 AM, Gordon Keiser <gkeiser at arxan.com> wrote: > Cool, I&...