similar to: RFC: Allowing @llvm.objectsize to be more conservative with null.

Hi George, Have you considered changing our existing behavior to match GCC's builtin_object_size instead of adding a new parameter? That may be simpler overall. There's also a clear upgrade strategy -- fold every old style call to "<min> ? 0 : 1". You probably already know this, but GCC folds builtin_object_size(0, 0) to -1 and builtin_object_size(0, 2) to 0. We'll

Hi George, On Mon, Jan 2, 2017 at 10:41 AM, George Burgess IV <george.burgess.iv at gmail.com> wrote: > Thanks for the comments! > >> Have you considered changing our existing behavior to match GCC's >> builtin_object_size instead of adding a new parameter > > Yup! My issue with turning `i1 %min` into `i8 %flags` is that > __builtin_object_size would get

Hi! This is an artifact of how LLVM works. Essentially, LLVM detects that `var` is unused and deletes it before it tries to lower the `llvm.objectsize` (which is what clang lowers `__builtin_object_size` to) call to a constant. While this isn't ideal, I don't think it realistically a problem, because `var` must be otherwise unused for this behavior to occur, and the whole purpose of

Hello LLVMer, I use dragonegg to generate LLVM bitcode. Then I use LLVM interpreter to execute what I get from compilation. However an error occurred and the error message is: "LLVM ERROR: Code generator does not support intrinsic function 'llvm.objectsize.i64'!." As far as I know, objectsize intrinsic is equivalent to gcc built-in function __builtin_object_size. But I don't

I made a mistake here, I get zero same as you. I want to fix it to get correct value. On 16.03.2016. 19:28, Duncan P. N. Exon Smith wrote: >> On 2016-Mar-16, at 09:39, Strahinja Petrovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Optimizer doesn't know how to calculate the object size when it finds condition that cannot be eliminated. There is example:

Optimizer doesn't know how to calculate the object size when it finds condition that cannot be eliminated. There is example: ----------------------------------------------- #include<stdlib.h> #define STATIC_BUF_SIZE 10 #define LARGER_BUF_SIZE 30 size_t foo(int flag) { char *cptr; char chararray[LARGER_BUF_SIZE]; char chararray2[STATIC_BUF_SIZE]; if(flag) cptr =

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

> we lower llvm.objectsize later than we should Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity. (To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Nuno and Arnold: > > Thank you all for the input. > > Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. > A clique is statically or dynamically allocated type-free stretch of memory. A "clique" > 1) is maximal in the sense

The documentation of LLVM says that "The llvm.objectsize intrinsic is lowered to a constant representing the size of the object concerned". I'm attempting to lower this intrinsic function to a constant in a pass. Below is the code snippet that I wrote: for (BasicBlock::iterator i = b.begin(), ie = b.end(); (i != ie) && (block_split == false);) { IntrinsicInst *ii =

Thanks for your reply. I'm attempting to expand KLEE to support this intrinsic function. That's why I need to handle this myself. According to the reply, the correct implementation should first find the definition of the object and then determine the size of the object. BTW, can I just refer to the implementation in InstCombineCalls.cpp. On Wed, Nov 5, 2014 at 2:24 PM, Matt Arsenault

Hi all, Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend and the C backend I see it converting regular (non-checking) memcpy and memset calls to __memset_chk and __memcpy_chk already at the IR stage. Then in the CBE output these are retained as gcc builtin functions. In a similar manner, llvm.objectsize.* calls are replaced with __builtin_object_size calls, another gcc

On 2/27/13 11:21 AM, Arnold Schwaighofer wrote: > On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> Hi, Nuno and Arnold: >> >> Thank you all for the input. >> >> Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. >> A clique is statically or dynamically allocated

> In the "llvm.objectsize" context we pass an object "based on p" to getObjectSize: "p+50". In the basicaa context, we wanna know whether an access is beyond the bounds of an underlying object (undefined behavior land) so we pass the underlying object (which in your example would be the "p" returned from malloc) to the getObjectSize function. > > In

Hi, I have question about __builtin_object_size behaviour. LLVM for __builtin_object_size function doesn't calculate correct value when pointer is used only in __builtin_object_size function call, and never after that. For this case LLVM as result generates 0 or -1 depends of second argument of __builtin_object_size function. Is this correct behaviour or it should work as gcc (gcc

> Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend > and the C backend I see it converting regular (non-checking) memcpy and > memset calls to __memset_chk and __memcpy_chk already at the IR stage. Most probably these are changed due to defines in the system headers, so, compiler cannot do anything about this. You can hack on your system headers though. > In

This is a new build failure as of today. Does this look familiar to anyone? -bw llvm[2]: Compiling CommonProfiling.ll to CommonProfiling.bc for Debug build (bytecode) Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter