search for: undefvalues

2013/3/27 Nick Lewycky <nicholas at mxc.ca>: >The common idiom to delete any Value* is: > > V->replaceAllUsesWith(UndefValue::get(V->getType()); > V->eraseFromParent(); > > Does that work for functions? You may need to make sure the 'undef' has a > pointer to function type instead of the function type. > I tried this code sample, passing the type

...dle undef ^ undef -> 0 special case. This is a common // idiom (misuse). return Constant::getNullValue(C1->getType()); // Fallthrough case Instruction::Add: This function folds ‘undef xor undef’ into 0(getNullValue) at this case. At http://llvm.org/docs/LangRef.html#undefvalues, undef xor undef can also be evaluating to undef. ///////////////////////////// %A = xor undef, undef [...] Safe: %A = undef [...] This example points out that two undef operands are not necessarily the same. [...], but the short answer is that an undef "variable" can arbitraril...

Михаил wrote: > How correctly remove function from module? > For example: > > int f1(int x) { > ... > a = f2(smth); > ... > } > int f2 (int y) { > ... > b = f1(smth); > ... > } > > I need delete from module both f1 and f2. They haven't uses in other > part of module, but I can't delete them with eraseFromParent, because > they are use each

How correctly remove function from module? For example: int f1(int x) { ... a = f2(smth); ... } int f2 (int y) { ... b = f1(smth); ... } I need delete from module both f1 and f2. They haven't uses in other part of module, but I can't delete them with eraseFromParent, because they are use each other. Yours sincerely, Kadysev Mikhail -------------- next part

Hello David, I am having an issue with some custom intrinsics that return a token value: InstCombine deletes the users of the token but not the instruction that creates the token itself. The IR is still valid but it's wasted. The source of the issue is coming from an old patch of yours: commit 7204cff0a121ebc770cf81f7f94679ae7324daae Author: David Majnemer <david.majnemer at

Michael Smith wrote: > Well, line 364 wasn't actually what was holding me up, so it's a bad > example, but the problem's still relevant. Using cast<...>(iter), > dyn_cast<...>(iter), or isa<...>(iter) results in the error messages > mentioned below. .... > When compiling LoadValueNumbering.cpp, I get the following errors: > >

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

Well, line 364 wasn't actually what was holding me up, so it's a bad example, but the problem's still relevant. Using cast<...>(iter), dyn_cast<...>(iter), or isa<...>(iter) results in the error messages mentioned below. ________________________________ When compiling LoadValueNumbering.cpp, I get the following errors:

Thanks, but I replaceAllUsesWith() - works well, but I still get bug in eraseFromParent(): While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi An asserting value handle still pointed to this value! UNREACHABLE executed at /Users/neonomaly/LLVM/LLVM/lib/VMCore/Value.cpp:561! Yours sincerely, Kadysev Mikhail 21.04.2012, в 23:45, Nick Lewycky написал(а): > Михаил wrote: >> How correctly

Hi, For a small case, that calls NULL pointer function. LLVM explicitly converts It to a store because it thinks it is not reachable like calling undefvalue. In InstCombineCalls.cpp:930 I think it is not a right approach because calling null pointer function Will segfault the program. Converting to a store will make program pass Silently. This changes the behavior of a program.

> On May 6, 2020, at 21:53, Krzysztof Parzyszek <kparzysz at quicinc.com> wrote: > > You can > 1. extract individual elements of {i8*, i64}, > 2. bitcast the first to some_struct*, > 3. insert them into a new struct of type {some_struct*, i64}. Thanks for the help. I’m thinking the same way. Now I’m stuck with how to create a struct; I know how to create a

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

Does anyone know how to instrument *double* to <2 x doulbe>**, e.g., 2.2 --> <2.2, 2.2>? For example, I want to change the following IR code %arrayidx1 = getelementptr inbounds [100 x double]* @main.B, i32 0, i32 %i.021 %1 = load double* %arrayidx1, align 4, !tbaa !0 to: %arrayidx1 = getelementptr inbounds [100 x double]* @main.B, i32 0, i32 %i.021 %1 = bitcast double* %arrayidx1

Hi David, Looking at the original bug, it seems like a straightforward undef-propagation bug to me -- SCCP was folding "or undef, constant" to "undef", which is wrong. Why is changing that not the fix? That is, some variant of diff --git a/lib/Transforms/Scalar/SCCP.cpp b/lib/Transforms/Scalar/SCCP.cpp index 8a6be97..45f1241 100644 --- a/lib/Transforms/Scalar/SCCP.cpp +++

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >

It is ModulePass with AnalysisUsage of CallGraph Yours sincerely, Kadysev Mikhail 22.04.2012, в 5:20, Nick Lewycky написал(а): > Михаил wrote: >> Thanks, but I replaceAllUsesWith() - works well, but I still get bug in >> eraseFromParent(): >> >> While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi >> An asserting value handle still pointed to this value! >>

Chris Lattner wrote: > On Wed, 10 May 2006, Nick Lewycky wrote: > >>> Then just run the SCCP pass, and check to see if any operands satisfy >>> the predicate "isa<UndefValue>(V)". LLVM explicitly represents >>> undefined values. >> >> >> I have a case where it doesn't, but perhaps the SCCP pass isn't to blame: >>

On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi David, > > Looking at the original bug, it seems like a straightforward > undef-propagation bug to me -- SCCP was folding "or undef, constant" > to "undef", which is wrong. Why is changing that not the fix? That > is, some variant of > You would still

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

Hello there, I'm writing a transformation pass for LLVM, and I hoped to use dce to clean up the resulting code after my pass. I just have some questions about LLVM's dce implementation. Well, my transformation is a function pass, and, after the changes are made, some instructions are not needed anymore. In order to easily get rid of those instructions, I'm setting all their uses to