search for: const_cast

..... // Initialize a compiler invocation object from the clang (-cc1) arguments. const driver::ArgStringList &CCArgs = Cmd->getArguments(); llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); CompilerInvocation::CreateFromArgs(*CI, const_cast<const char **>(CCArgs.data()), const_cast<const char **>(CCArgs.data()) + CCArgs.size(), Diags); // Show the invocation, with -v. if (CI->getHeaderSearchOpts().Verbos...

...object from the clang (-cc1) >> arguments. >> const driver::ArgStringList &CCArgs = Cmd->getArguments(); >> llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); >> CompilerInvocation::CreateFromArgs(*CI, >> const_cast<const char >> **>(CCArgs.data()), >> const_cast<const char >> **>(CCArgs.data()) + >> CCArgs.size(), >> Diags); >> >> // Show the invo...

Currently, member functions like File::defined() return an iterator for const atoms. But we don't actually treat atoms as consts -- we updates atoms in many places including the core resolver. We have too many const_casts in our code. It just doesn't make sense. I'm making a change to make atoms non-const. Please hit reply if you have any concerns. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150407/a1de5102/attac...

...ze a compiler invocation object from the clang (-cc1) arguments. > const driver::ArgStringList &CCArgs = Cmd->getArguments(); > llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); > CompilerInvocation::CreateFromArgs(*CI, > const_cast<const char > **>(CCArgs.data()), > const_cast<const char > **>(CCArgs.data()) + > CCArgs.size(), > Diags); > > // Show the invocation, with -v. > if (C...

...a source file compilation. Here’s the most illuminating debugging information I could pull out of a frame: (lldb) frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399 396 MDNode *Node = const_cast<MDNode *>(DbgNode); 397 const MDNode *DN = D; 398 const Value *V = cast_or_null<Value>(DN); -> 399 Node->replaceAllUsesWith(const_cast<Value *>(V)); 400 MDNode::deleteTemporary(Node); 401 } 402 (lldb) print Node (llvm::MDNode *) $3 = 0x000000011...

...clang (-cc1) >>> arguments. >>> const driver::ArgStringList &CCArgs = Cmd->getArguments(); >>> llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); >>> CompilerInvocation::CreateFromArgs(*CI, >>> const_cast<const char >>> **>(CCArgs.data()), >>> const_cast<const char >>> **>(CCArgs.data()) + >>> CCArgs.size(), >>> Diags); >>> >...

...ut.txt The code itself is in http://zigzag.lvk.cs.msu.su/~ghost/localize/code/ The GlobalsModRef::getModRefInfo has this logic: // If we are asking for mod/ref info of a direct call with a pointer to a // global we are tracking, return information if we have it. if (GlobalValue *GV = const_cast<GlobalValue*>(getUnderlyingObject(P))) if (GV->hasInternalLinkage()) So, no information is produced for external variables, the function calls Aliasanalysis::getModRefInfo, which sees that called function may write to memory, and returns true for all global variables. Anything I...

..., which would pollute all analysis after that point with those unwanted flags. I don't know if any callers actually do this but I could see it being useful for looking at hypothetical cases. To some degree mutation of wrapping flags is part of the design, because SCEVAddRecExprs are explicitly const_casted to add flags in multiple places so that they can be found again later. But that might not be quite so harmful because they at least contain a Loop as a contextual cue that prevents some leaking. So, my real question is does anyone know what the contract with ScalarEvolution is? I see a few possi...

...DeclarationName instance using StringRef ,because in the current trunk code snap ,we see that the DeclarationName can be constructed using the IdentifierInfo or Objc Selector or CXXOperatorId etc as argument in the constructor . The code i.e void appendExtern(StringRef Sr) { char *ExternChar = const_cast<char *> (Sr.data()); *Ptr =reinterpret_cast<void *>(ExternChar); this->ExternName = DeclarationName::getFromOpaquePtr(Ptr); } the above is kind of hack ,may result in dangling memory references ,Any thoughts on this ? we thought to change the DeclarationName class ,with addi...

...} // Initialize a compiler invocation object from the clang (-cc1) arguments. const driver::ArgStringList &CCArgs = Cmd->getArguments(); llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); CompilerInvocation::CreateFromArgs(*CI, const_cast<const char **>(CCArgs.data()), const_cast<const char **>(CCArgs.data()) + CCArgs.size(), Diags); // Show the invocation, with -v. if (CI->getHeaderSearchOpts().Verbos...

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

...lysis after that > point with those unwanted flags. I don't know if any callers actually > do this but I could see it being useful for looking at hypothetical > cases. > > To some degree mutation of wrapping flags is part of the design, > because SCEVAddRecExprs are explicitly const_casted to add flags in > multiple places so that they can be found again later. But that might > not be quite so harmful because they at least contain a Loop as a > contextual cue that prevents some leaking. > > So, my real question is does anyone know what the contract with > ScalarEv...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedestkop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp index b8d0d3e..d566c99

...1); + } strange indentation +++ lib/Bitcode/Reader/BitcodeReader.cpp (Arbeitskopie) +void BitcodeReaderValueList::resize(unsigned Desired) { + if (Desired > Capacity) + { Please put brace on same line as if. - Constant *C= ConstantExpr::getFCmp(FCmpInst::FCMP_OEQ, - const_cast<Constant*>(CP1->getOperand(i)), - const_cast<Constant*>(CP2->getOperand(i))); + Constant *C = ConstantExpr::getFCmp(FCmpInst::FCMP_OEQ, + CP1->getOperand(i), + CP2-&g...

...> What I describe is how, AFAICT, it is implemented in all of the alias > passes. > For example, SCEVAA, which actually computes the recurrences for these > loop expressions, has this: > // This is ScalarEvolutionAliasAnalysis. Get the SCEVs! > const SCEV *AS = SE->getSCEV(const_cast<Value *>(LocA.Ptr)); > const SCEV *BS = SE->getSCEV(const_cast<Value *>(LocB.Ptr)); > > // If they evaluate to the same expression, it's a MustAlias. > if (AS == BS) return MustAlias; > > > IE if the two recurrences for the pointers are equal, it'...

...t illuminating debugging information I could pull out of a frame: >> >> >> (lldb) >> frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399 >> 396 MDNode *Node = const_cast<MDNode *>(DbgNode); >> 397 const MDNode *DN = D; >> 398 const Value *V = cast_or_null<Value>(DN); >> -> 399 Node->replaceAllUsesWith(const_cast<Value *>(V)); >> 400 MDNode::deleteTemporary(Node); >> 401 } >> 402 >&gt...

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful

Hello all, I've read the documentation on alias analysis, and I think I understand it literally, but I just want to be sure, because it seems a bit strange. As it says on this web page <http://llvm.org/docs/AliasAnalysis.html>, The MayAlias response is used whenever the two pointers might refer to the > same object. > > The PartialAlias response is used when the two memory

...heck and the cast. I tried this (using getSimplifiedValue), but got further problems and had to add a specialization +template<typename From> struct simplify_type<From*const> { + typedef From* SimpleType; + static SimpleType &getSimplifiedValue(From*const &Val) { + return const_cast<From*&>(Val); + } +}; Is there a simpler way to accomplish this? Cheers, Gabor