similar to: [SSP] Simplifying SSP code paths

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Some background: We have an issue with in loop values being correctly marked uniform but the out of loop uses can be non-uniform. Currently the out of loop users are not marked as divergent because the in loop value is uniform inside the loop. We have gotten around this problem for the moment by applying LCSSA which inserts a PHI in the loop exit for the in loop uniform value that allows the

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Any comments at all on this? Chandler perhaps? I've since dug a bit further, and it seems like the template-based solution wouldn't work anyway because DLL loading on Windows can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the

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

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

PR43308 describes a case where StackProtector fails to protect against a fairly simple smash. This problem started after r363169, which removed StackProtector's own analysis function HasAddressTaken, and used CaptureTracking's PointerMayBeCaptured instead. The problem here is that "pointer is captured" and "pointer could be used to smash the stack" are not equivalent

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

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

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,

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 Jul 11, 2011, at 3:41 PM, Dan Gohman wrote: > On Jul 11, 2011, at 3:06 PM, Eli Friedman wrote: > >> 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: >>> >>> This seems odd. I'd think that fast-isel should be able to materialize the constants when

On Jul 11, 2011, at 3:06 PM, Eli Friedman wrote: > 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: >> >> 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

On Fri, 2013-05-17 at 15:32 -0700, Jakob Stoklund Olesen wrote: > On May 17, 2013, at 2:04 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > > Hello, > > > > In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and > > http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along > > with some follow-up

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

> On May 9, 2017, at 11:47 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Kristof, > >> On May 9, 2017, at 3:41 AM, Kristof Beyls <kristof.beyls at arm.com <mailto:kristof.beyls at arm.com>> wrote: >> >> Great Quentin :). >> >> I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g

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

I'm not very familiar with relocations but your fix looks the same as ARMTargetLowering::LowerCall, so from that perspective it lgtm (but I may be missing something). On Wed, Aug 21, 2013 at 8:04 AM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > Hi Anton and JF, > > Thanks for your review. After reading the source code more carefully, I > have come up with a

Filing a bug would be a good start, go ahead and cc me and jfb at google.com. Thanks! -eric On Tue, Aug 20, 2013 at 6:10 PM, Gordon Keiser <gkeiser at arxan.com> wrote: > 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