search for: objectsize

...ou 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 lowered like: > > __builtin_object_size(p, 0) -> @llvm.objectsize(i8* %p, i8 2) > __builtin_object_size(p, 1) -> @llvm.objectsize(i8* %p, i8 2) > __builtin_object_size(p, 2) -> @llvm.objectsize(i8* %p, i8 3) > (__builtin_object_size(p, 3) doesn't actually get lowered) > > ...Which might be a bit surprising to some people. If we think that...

...sday. If I don't get comments by EOD Thursday, I'll > assume everyone's OK with this and put together a patch. > > On Wed, Dec 21, 2016 at 11:44 AM, George Burgess IV > <george.burgess.iv at gmail.com> wrote: >> >> 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 wi...

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 #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic param...

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

...e 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 <Matthew.Arsenault at amd.com> wrote: > On 11/05/2014 02:04 PM, Dingbao Xie wrote: > > 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: > > Why do you need to handle this yourself? This should already be handl...

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

...2009, at 3:22 PM, Bill Wendling wrote: > 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 #1 is wrong! > i64 (i8*, i32)* @llvm.objectsize.i64 > Intrinsic parameter #1 is wrong! > i64 (i8*, i3...

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

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

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

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 call __builtin_object_size explicitly in my source code. Maybe headers what I include call the built-in somewhere. How do I eliminate such built-in function call in...

...oo function). In case when condition can't be eliminated compiler should calculate object size depending on second argument of __builtin_object_size function (taking minimum or maximum value from condition). In this example, the result should be 10 with -fno-inline. If I replace the llvm.objectsize with the constant in foo() depending on the second argument, the result will be correct with -fno-inline (10), but incorrect without the flag. This is because foo() is inlined, the condition can be eliminated, and the result should be 30. I resolved this problem by adding third argument in ll...

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() also expects the same definition, but I didn't r...

...to by ptr p" seems to take on two meanings. Suppose the corresponding clique of the "object", regardless which context it is in, is C. a): the object refers to the stretch of memory staring from p to the end of the C. b): the entire clique C. In the context of llvm.objectsize(). As you guys pointed out, the "object" take meaning of a). If would not be useful if it take meaning b) as the compiler is not able to use this info to convert run-time testing into a static test. In the context of memory disambiguation, the "object" take meaning of b...

...be assumed "no alias" if the access size of an memory access (i.e. a load or store) is bigger than the underlying object of the other accessed object. For you example below: V1Size = sizeof(mydata) V2Size = say 4 assuming that GetUnderlyingObject for addr1 and addr2 returns mydata: getObjectSize(O1) = sizeof(mydata) getObjectSize(O2) = sizeof(mydata) this should be isObjectSmallerThan(O2, V1Size) == false isObjectSmallerThan(O1, V2Size) == false ?? > > In llvm, the "object pointed to by ptr p" seems to take on two meanings. Suppose the corresponding > clique of...

...he other accessed object. > > For you example below: > > V1Size = sizeof(mydata) > V2Size = say 4 > > assuming that GetUnderlyingObject for addr1 and addr2 returns mydata: This assumption is wrong. The GetUnderlyingObject() return phi node instead of &mydata. > > getObjectSize(O1) = sizeof(mydata) > getObjectSize(O2) = sizeof(mydata) > > this should be > isObjectSmallerThan(O2, V1Size) == false > isObjectSmallerThan(O1, V2Size) == false > > ?? > >> In llvm, the "object pointed to by ptr p" seems to take on two meanings. Suppos...

> 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&quot...

...). In case when condition can't be eliminated compiler should calculate object size depending on second argument of __builtin_object_size function (taking minimum or maximum value from condition). In this example, the result should be 10 with -fno-inline. >> >> If I replace the llvm.objectsize with the constant in foo() depending on the second argument, the result will be correct with -fno-inline (10), but incorrect without the flag. This is because foo() is inlined, the condition can be eliminated, and the result should be 30. >> >> I resolved this problem by adding third ar...

>>>>> Travers Ching >>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > I have a toy alt-rep string package that generates > randomly seeded strings. example: library(altstringisode) > x <- altrandomStrings(1e8) head(x) [1] > "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1" > "5PN2qmWqBlQ9wQj99nsQzldVI5ZuGX" ... etc

Travers, Great to hear you're trying out the ALTREP stuff, good on you :). Did you mean the get_altstring_Elt_method? I see the code in size.c within utils that grabs each element, but I don't see any setting (and the setters are noops currently anyway they just do things the old way). One thing we have to decide is what object.size means for an altrep. I tend to think it should mean