similar to: [LLVMdev] Marking source locations without interfering with optimization?

On Fri, 19 Aug 2005, Michael McCracken wrote: > I've been thinking of adding an instruction, and I'm following the > advice in the docs to consult the list before doing something rash. Always a good idea! :) Instead of adding an instruction, I'd suggest adding an intrinsic. You can mark intrinsics as not reading/writing to memory (see lib/Analysis/BasicAliasAnalysis.cpp for

Chris, Thanks for the suggestions. On 8/22/05, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 19 Aug 2005, Michael McCracken wrote: > > > I've been thinking of adding an instruction, and I'm following the > > advice in the docs to consult the list before doing something rash. > > Always a good idea! :) Instead of adding an instruction, I'd

On Tue, 23 Aug 2005, Michael McCracken wrote: >> Okay... this is tricky. Anything that will bind to variables will >> prevent modification to the variable. > > I see - so if I wanted to use my earlier approach, I'd need to change every > optimization and analysis to treat the 'marker' instructions specially as > instructions that don't modify their

On 8/23/05, Chris Lattner <sabre at nondot.org> wrote: > On Tue, 23 Aug 2005, Michael McCracken wrote: > >> Okay... this is tricky. Anything that will bind to variables will > >> prevent modification to the variable. > > > > I see - so if I wanted to use my earlier approach, I'd need to change every > > optimization and analysis to treat the

Greetings all, I am picking up the work that was started in https://reviews.llvm.org/D27133 — adding support for an element-atomic memcpy/memset/memmove to LLVM. I would appreciate suggestions/thoughts/advice/comments on how to best proceed with this work in a way that will be acceptable to the LLVM group. I apologize in advance; this is going to be a long one... **Background** Loads/stores

Hi Sanjoy, Responses inlined… > On May 8, 2017, at 12:49 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Daniel, > > [+CC Mehdi, Vedant for the auto upgrade issue] > > On Mon, May 8, 2017 at 7:54 AM, Daniel Neilson via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> **Method** >> >> Clearly we are going to have to teach

Hi, I will try to explain by giving an example. Let's say that I have an intrinsic: int llvm.myintrinsic(int) I have a function: int myintrinsic_handler(int) When %var = call int %llvm.myintrinsic( int %arg ) is met in the code, I want the code generator put in its place: a call to function "myintrinsic_handler" (i.e. %var = call int %myintrinsic_handler( int %arg ) ) or

On Sat, 2007-03-31 at 12:38 -0800, Chris Lattner wrote: > >> 3. Can I introduce an intrinsic that is actually a call to my function > >> that implements the logic? I suppose it is possible but unfortunately > >> I couldn't figure it out. For example, in GCC we can write an > >> intrinsic that translates to a C code. > > > > As part of PR1297

Matt, The added intrinsic in DAG looks like: 0xbedb698: i32 = llvm.MyIntrinsic 0xbedb200, 0xbedac18 [ORD=4] The builtin in DAG looks like: 0xbedb2a8: i32,ch = llvm 0xbedb158:1, 0xbedb200, 0xbedb158 [ORD=7] [ID=16] The only difference I'm seeing is the extra operand, which is a 'ch' from a load. On Tue, Feb 2, 2016 at 3:55 PM, Matt Arsenault <arsenm2 at gmail.com>

>> 3. Can I introduce an intrinsic that is actually a call to my function >> that implements the logic? I suppose it is possible but unfortunately >> I couldn't figure it out. For example, in GCC we can write an >> intrinsic that translates to a C code. > > As part of PR1297 (http://llvm.org/PR1297) I am about to make this > happen. There are certain kinds of

Is there a way to implement an intrinsic that looks like a conditional branch so that it has 2 edges to 2 basic blocks? Taking a step back, I'm trying to make a special branch where Passes treat it just like a regular conditional branch except that it's condition is opaque to everyone, so it isn't removed by optimizations. Additionally, the special branch would codegen (to x86) to

I've tried all the types (both for result and Intrinsic ID), can't seem to find what cast is causing the issue here. On Fri, Jun 24, 2016 at 11:47 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That's what I thought but I got the same error with: > > DAG.getNode(ISD::INTRINSIC_WO_CHAIN, DL, VT, > DAG.getTargetConstant(Intrinsic::my_intrinsic, DL, MVT::i16), LHS);

The intrinsic ID is an int, not a float. —escha > On Jun 24, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > given the following C code: > > float b=16, a=0; > int main() { > float a = sqrt(b); > return0; > } > > I'm trying to lower FSQRT down, but getting a casting issue, my code is: > > SDValue

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison

I'm using Windows 8.1, and every time I run check-clang, I eventually end up with a bunch of hung processes. Generally this is an instance of clang.exe, a bunch of instances of FileCheck.exe, and occasionally an llc.exe and an opt.exe. Inside, the processes are all hung inside of calls to WriteFile() attempting to write to stdout. I notice some of the tests fail with output indicating that

cmake -E cmake_progress_report llvm-3.8.0.src_bld_x86_64-rhel6.4-linux-gnu/CMakeFiles In file included from llvm-3.8.0.src/projects/libcxx/include/__hash_table:19:0, from llvm-3.8.0.src/projects/libcxx/src/hash.cpp:10: llvm-3.8.0.src/projects/libcxx/include/cmath:310:9: error: '::signbit' has not been declared using ::signbit; ^

On Mon, Apr 14, 2008 at 5:11 PM, Chris Lattner <sabre at nondot.org> wrote: > Why not something like: > %x = llvm.myintrinsic() > br i1 %x, label %T, label %F Right. That's exactly what I meant in the last paragraph of the original message. The reason for not wanting this is that %x actually always turns out to be 1 (on architectures that support it), so %T is always

Dear R People: I have the following data frame: > x.df date cond freq 1 04/01/09 Fever 12 2 04/02/09 Fever 11 3 04/03/09 Fever 10 4 04/04/09 Fever 13 5 04/05/09 Fever 6 6 04/01/09 Rash 6 7 04/02/09 Rash 10 8 04/03/09 Rash 9 9 04/04/09 Rash 10 10 04/05/09 Rash 8 11 04/01/09

Hi, The C backend in llc generates code like: static inline int llvm_fcmp_ord(double X, double Y) { return X == X && Y == Y; } static inline int llvm_fcmp_uno(double X, double Y) { return X != X || Y != Y; } First of all it generates a warning by clang and gcc (with certain flags): x.cbe.c:130: warning: comparing floating point with == or != is unsafe Now, C99 provides a macro for this

Dear R People: I have the following data set with the columns DATE, GENDER, and Co. Co has 8 possible options. > a.df[1:10,] DATE GENDER Co 1 2009-04-16 F Rash 2 2009-04-16 F Other 3 2009-04-16 M Botulinic 4 2009-04-16 M Other 5 2009-04-16 M Constitutional 6 2009-04-16 F Other 7 2009-04-16