Displaying 15 results from an estimated 15 matches for "madechanges".
Did you mean:
madechange
2011 Oct 08
0
[LLVMdev] Initializing GC roots
On Oct 6, 2011, at 17:19, Yiannis Tsiouris wrote:
> Hello all,
>
> I set: InitRoots = true; in my gc plugin as i want the roots to be
> initialized to the "null" value.
> Is there a way to define which value should be the initial one? For
> example, i would like to initialize my roots to -5 (tagged, null value
> for the GC in my runtime system) instead of 0.
>
2011 Oct 06
2
[LLVMdev] Initializing GC roots
Hello all,
I set: InitRoots = true; in my gc plugin as i want the roots to be
initialized to the "null" value.
Is there a way to define which value should be the initial one? For
example, i would like to initialize my roots to -5 (tagged, null value
for the GC in my runtime system) instead of 0.
Ofcourse, i could do it in the frontend (storing -5 to all GC roots),
but i was wondering
2015 Sep 13
3
RFC: faster simplifyInstructionsInBlock/SimplifyInstructions pass
LLVM has two similar bits of infrastructure: a simplifyInstructionsInBlock function and a SimplifyInstructions pass, both intended to be lightweight “fix up this code without doing serious optimizations” functions, as far as I can tell. I don’t think either is used in a performance-sensitive place in-tree; the former is mostly called in minor places when doing CFG twiddling, and the latter seems
2015 May 05
1
[LLVMdev] Naryreassociate vs reassociate
On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote:
> Hi Daniel,
>
> I presume you mean, instead of assigning function arguments distinct ranks
> (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we
> should group function arguments in favor of existing pairings.
Existing = pairings reassociate already chose before
*not*
existing
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
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
2008 Nov 07
2
[LLVMdev] non-pointer gcroot
Hi
I'm getting an assert in LowerIntrinsics::InsertRootInitializers
because I'm gcroot'ing an alloca to a non-pointer.
I was hoping to modify InsertRootInitializers to memset the structure
in the case that it's not a pointer, but I'm not sure how to. Can
anyone suggest what should go at "todo; something here"?
...
for (AllocaInst **I = Roots, **E = Roots +
2016 Aug 24
2
LLVM 3.9 RC2's SCCP pass removing calls to external functions?!
Hi Félix,
Sanjoy Das wrote:
> Félix Cloutier via llvm-dev wrote:
> > Assuming that this is a bug, what are the next steps?
>
> Looks like you already have a very small test case -- have you tried
> sticking it in a debugger to see why SCCP thinks removing the call is
> okay?
>
> Alternatively, file a bug at llvm.org/bugs and someone will get to it.
The third
2019 Jun 04
2
is this a bug in PruneEH?
I have the following C source:
extern unsigned int donut;
void f1();
void f2();
void f1()
{
unsigned int *magic = &donut;
if (*magic != 286529877) {
f2();
}
}
void f2() {
/* Loop here forever if application is built with wrong version of ROM image */
while(1) {
;
}
}
The -O2 level PruneEH pass uses SimplifyFunction() which contains this code:
for
2009 Feb 19
0
[LLVMdev] Bug in BranchFolding.cpp:OptimizeBlock
I've ran across an issue in BranchFolding.cpp where it is incorrectly
folding a branch to the wrong fallthrough location. This is in LLVM 2.4
and seems to be in 2.5 also.
The code in question is:
void BranchFolder::OptimizeBlock(MachineBasicBlock *MBB) {
MachineFunction::iterator FallThrough = MBB;
++FallThrough;
// If this block is empty, make everyone use its fall-through, not
2009 Mar 20
0
[LLVMdev] GC interface suggestions
Hello,
I have a few suggestions for the GC interface. First, initialization of roots fails if the root isn't just a pointer. Some implementations require more data than just the pointer for handling references to the interior of an aggregate. On my end it just required changing ConstantPointerNull::get() to Constant::GetNullValue() to support fat pointers. The roots that were being
2007 Jul 12
0
[LLVMdev] [PATCH] trivial: remove unused variable
fix the following warning:
FastDSE.cpp: In member function ‘bool<unnamed>::FDSE::handleEndBlock(llvm::BasicBlock&, llvm::SetVector<llvm::Instruction*, std::vector<llvm::Instruction*, std::allocator<llvm::Instruction*> >, llvm::SmallSet<llvm::Instruction*, 16u> >&)’:
FastDSE.cpp:174: warning: unused variable ‘AA’
--- a/lib/Transforms/Scalar/FastDSE.cpp
2008 Nov 08
0
[LLVMdev] non-pointer gcroot
On Nov 7, 2008, at 15:29, Scott Graham wrote:
> I'm getting an assert in LowerIntrinsics::InsertRootInitializers
> because I'm gcroot'ing an alloca to a non-pointer.
>
> I was hoping to modify InsertRootInitializers to memset the
> structure in the case that it's not a pointer, but I'm not sure how
> to. Can anyone suggest what should go at "todo;
2015 Dec 03
3
Function attributes for LibFunc and its impact on GlobalsAA
----- Original Message -----
> From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Vaivaswatha Nagaraj" <vn at compilertree.com>
> Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, December 3, 2015 4:41:46 AM
> Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA
>
>
2006 May 17
0
[LLVMdev] Obfuscation with LLVM
Hi all,
I was trying to implement an obfuscation tool for C-code on the basis of
LLVM. I got a prototype of the simple obfuscation transformation which
converting control flow graph to something like a state machine. I am not
sure I will have time to work on extending further this tool with new
transformations like opaque predicates and decided to put here source code I
have by now with hope
2016 Aug 24
2
LLVM 3.9 RC2's SCCP pass removing calls to external functions?!
...(Inst->getType()->isVoidTy() || isa<TerminatorInst>(Inst))
> continue;
>
> if (tryToReplaceInstWithConstant(Solver, Inst,
> true /* shouldEraseFromParent */)) {
> // Hey, we just changed something!
> MadeChanges = true;
> ++NumInstRemoved;
> }
>
> It should not be passing in true for shouldEraseFromParent. I think
> the right fix here is to not have the shouldEraseFromParent parameter
> at all, but in tryToReplaceInstWithConstant to do:
>
> // replace Inst with cons...