Displaying 7 results from an estimated 7 matches for "availablevalue".
Did you mean:
availablevalues
2020 Jan 06
2
Question about opt-report strings
...izationRemark(DEBUG_TYPE, "LoadElim", LI)
<< "load of type " << NV("Type", LI->getType()) << " eliminated"
<< setExtraArgs() << " in favor of "
<< NV("InfavorOfValue", AvailableValue);
});
There is some C++ magic going on behind the scenes here, and it makes for a nice interface, but I'm not clear about what ends up being stored where. I think within DiagnosticInfoOptimizationBase all the string parts of this get stored in a vector of name-value pairs with the unnamed st...
2016 Mar 15
7
RFC: DenseMap grow() slowness
...igned InstCount = 0;
unsigned LoadCount = 0;
unsigned CallCount = 0;
for (inst_iterator FI = inst_begin(F), FE = inst_end(F); FI != FE; ++FI) {
if (FI->mayReadOrWriteMemory())
++LoadCount;
else if (isa<CallInst>(*FI))
++CallCount;
else
++InstCount;
}
AvailableValues.resize(InstCount);
AvailableLoads.resize(LoadCount);
AvailableCalls.resize(CallCount);
But it does the job, and saves ~20% of time in EarlyCSE on my profiles. Yes, iterating over the entire function is way cheaper than grow(). Downsides are that while it’s still bounded by function size, it c...
2016 Jun 10
3
Early CSE clobbering llvm.assume
...that there is the potential for an easy
> fix. Here the issue appears to be that we hit
>
> if (Value *V = SimplifyInstruction(Inst, DL, &TLI, &DT, &AC))
>
> immediately replacing %1 with 3 before we even reach %3. If we were to
> record this replacement in EarlyCSE::AvailableValues, wouldn't that address
> the issue? I'll try this out and see.
>
> v/r,
> Josh
>
> On Fri, Jun 10, 2016 at 4:23 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
>
>> Yeah, that change is completely unrelated, that is about correctness,
>> this i...
2016 Mar 15
2
RFC: DenseMap grow() slowness
...for (inst_iterator FI = inst_begin(F), FE = inst_end(F); FI != FE; ++FI) {
>> if (FI->mayReadOrWriteMemory())
>> ++LoadCount;
>> else if (isa<CallInst>(*FI))
>> ++CallCount;
>> else
>> ++InstCount;
>> }
>> AvailableValues.resize(InstCount);
>> AvailableLoads.resize(LoadCount);
>> AvailableCalls.resize(CallCount);
>>
>> But it does the job, and saves ~20% of time in EarlyCSE on my profiles. Yes, iterating over the entire function is way cheaper than grow(). Downsides are that while it’s...
2016 Mar 15
2
RFC: DenseMap grow() slowness
...; unsigned CallCount = 0;
> for (inst_iterator FI = inst_begin(F), FE = inst_end(F); FI != FE; ++FI) {
> if (FI->mayReadOrWriteMemory())
> ++LoadCount;
> else if (isa<CallInst>(*FI))
> ++CallCount;
> else
> ++InstCount;
> }
> AvailableValues.resize(InstCount);
> AvailableLoads.resize(LoadCount);
> AvailableCalls.resize(CallCount);
>
> But it does the job, and saves ~20% of time in EarlyCSE on my profiles. Yes, iterating over the entire function is way cheaper than grow(). Downsides are that while it’s still bounded by...
2016 Jun 10
2
Early CSE clobbering llvm.assume
Yeah, that change is completely unrelated, that is about correctness, this
is about optimization.
I'm working on a proposal to just fix assume at some point to deal with the
former issue.
The problem with this testcase is that all the ways assume is propagate
expect the variable in the assume to later be used.
<This is the main way assume constants are propagated>
bool
2016 Apr 18
2
Different index types in GEPs -> non-aliasing?
...this little piece of code
in GVN::AnalyzeLoadAvailability that triggers
// Loading the allocation -> undef.
if (isa<AllocaInst>(DepInst) || isMallocLikeFn(DepInst, TLI) ||
// Loading immediately after lifetime begin -> undef.
isLifetimeStart(DepInst)) {
Res = AvailableValue::get(UndefValue::get(LI->getType()));
return true;
}
And the DepInst here is
%a = alloca [3 x i16]
and not the store
store i16 98, i16* %_tmp2
Digging further it seems the reason for this is that the alias analysis
considers the two pointers used to store and load the value 98 a...