Displaying 7 results from an estimated 7 matches for "numuseroperands".
2016 Feb 25
0
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
...tatic_cast<User *>(Usr);
if (Obj->HasHungOffUses) {
assert(!Obj->HasDescriptor && "not supported!");
Use **HungOffOperandList = static_cast<Use **>(Usr) - 1;
// drop the hung off uses.
Use::zap(*HungOffOperandList, *HungOffOperandList +
Obj->NumUserOperands,
/* Delete */ true);
::operator delete(HungOffOperandList);
} else if (Obj->HasDescriptor) {
Use *UseBegin = static_cast<Use *>(Usr) - Obj->NumUserOperands;
Use::zap(UseBegin, UseBegin + Obj->NumUserOperands, /* Delete */ false);
auto *DI = reinterpret...
2016 Feb 26
2
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
...; if (Obj->HasHungOffUses) {
> assert(!Obj->HasDescriptor && "not supported!");
>
> Use **HungOffOperandList = static_cast<Use **>(Usr) - 1;
> // drop the hung off uses.
> Use::zap(*HungOffOperandList, *HungOffOperandList +
> Obj->NumUserOperands,
> /* Delete */ true);
> ::operator delete(HungOffOperandList);
> } else if (Obj->HasDescriptor) {
> Use *UseBegin = static_cast<Use *>(Usr) - Obj->NumUserOperands;
> Use::zap(UseBegin, UseBegin + Obj->NumUserOperands, /* Delete */
> false...
2016 Feb 25
2
Heap problems with 3.8.0rc2 in combination with vs2015 sp1
I made the llvm::Function() constructor public (for testing purpose) and
used the non-overloaded new.
auto func = ::new llvm::Function(...)
if (func) func->eraseFromParent();
And the heap corruption is gone! Did something changed in llvm::User::new
between 3.7.1 and 3.8.0 ?
I found a bug in llvm ?
On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote:
> I
2019 Mar 18
2
[RFC] Making space for a flush-to-zero flag in FastMathFlags
On Sun, Mar 17, 2019 at 1:47 PM Craig Topper <craig.topper at gmail.com> wrote:
> Can we move HasValueHandle out of the byte used for SubClassOptionalData and move it to the flags at the bottom of value by shrinking NumUserOperands to 27?
I like this approach because it is less work for me. :)
But I agree with Sanjay below that this only kicks the can slightly
further down the road (solutions (2) and (3) also have the same
problem). Let's see if we can agree on a more future proof solution.
-- Sanjoy
>
> ~Craig...
2019 Mar 16
3
[RFC] Making space for a flush-to-zero flag in FastMathFlags
Hi,
I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags,
but we've already used up the 7 bits available in
Value::SubclassOptionalData (the "backing storage" for
FPMathOperator::getFastMathFlags()). These are the possibilities I
can think of:
1. Increase the size of FPMathOperator. This gives us some additional
bits for FTZ and other fastmath flags we'd want
2019 Mar 18
3
[RFC] Making space for a flush-to-zero flag in FastMathFlags
...we need to make FMF changes regardless of FTZ.
On Sun, Mar 17, 2019 at 2:47 PM Craig Topper via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Can we move HasValueHandle out of the byte used for SubClassOptionalData
> and move it to the flags at the bottom of value by
> shrinking NumUserOperands to 27?
>
> ~Craig
>
>
> On Sat, Mar 16, 2019 at 12:51 PM Sanjoy Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags,
>> but we've already used up the 7 bits...
2015 Sep 14
7
RFC: speedups with instruction side-data (ADCE, perhaps others?)
I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a