similar to: Problem with __builtin_object_size when it depends on a condition

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:

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

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

Hi everyone, I have a question about ARM 32 big endian calling convention. It's about sending small structures as function argument. For example if passing 3 chars in a structure should alignment in register (argument register for passing those chars in function) be right-adjusted ? LLVM (trunk version) is passing those chars left-adjusted in register, and trying to read them like they

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

tl;dr: We'd like to add a bit to @llvm.objectsize to make it optionally be conservative when it's handed a null pointer. Happy Wednesday! We're trying to fix PR23277, which is a bug about how clang+LLVM treat __builtin_object_size when it's given a null pointer. For compatibility with GCC, clang would like to be able to hand back a conservative result (e.g. (size_t)-1), but the

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

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

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

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

> 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

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

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the

> 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

Hello, (This is follow up from this thread: http://www.nabble.com/execution-time-of-.packages-td22304833.html but with a different focus) I am often confused by the result of the profiler, when a loop is involved. Consider these two scripts: script1: Rprof( ) x <- numeric( ) for( i in 1:10000){ x <- c( x, rnorm(10) ) } Rprof( NULL ) print( summaryRprof( ) ) script2:

Hi Consider the following example: f <- function(expr) g(expr) g <- function(expr) { ? h(expr) } h <- function(expr) { ? expr # evaluation happens here ? i(expr) } i <- function(expr) { ? expr # already evaluated, no costs here ? invisible() } rprof <- tempfile() Rprof(rprof) f(replicate(1e2, sample.int(1e4))) Rprof(NULL) cat(readLines(rprof), sep = "\n") #>

I came in to an email this morning that said basically the same thing for the reduced example we were looking at. However, the original IR it came from (before hand reduction) had the data layout set correctly, so there's probably still *something* going on. It's just not what I thought at first. :) Philip On 09/10/2014 02:26 AM, Roel Jordans wrote: > Looking at the -debug