Displaying 7 results from an estimated 7 matches for "availablevalues".
2020 Jan 06
2
Question about opt-report strings
Hi all,
I tried to poke my head into opt-report a while ago and didn't get very far. Now I'm looking at it again. I'm not sure I understand everything that's in place so my question here may be misguided.
I'm trying to understand the way strings are handled. When a remark is emitted, it seems that the string is constructed on the fly based on streaming inputs. For example,
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 co...
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 is...
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 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?
Hi,
It seems that opt thinks that the two pointers
%_tmp2 = getelementptr [3 x i16], [3 x i16]* %a, i16 0, i64 1
and
%_tmp4 = getelementptr [3 x i16], [3 x i16]* %a, i16 0, i16 1
does not alias? Is this intended or a bug?
Details below:
--------------
I found this when I ran opt on:
define i16 @f () {
%a = alloca [3 x i16]
; Write 98 at index 1 in the array.
; NB: using i64 as