search for: eliminates

On 20/05/2010, at 3:01 AM, Chris Lattner wrote: > > On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > >> Hi all, >> >> I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the

Hi all, I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: @global = global i32 0

Hi all, There might be a bug in DeadStoreElimination.cpp. This pass eliminates stores backwards aggressively in an end BB. It does not check dependencies on stores in an end BB though. For example, in this code snippet: ... 1. %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre, %entry.for.end_crit_edge ], [ %sum.safe_r42, %for.body ] 2. %call9 = call i32 @gettimeofday(%...

Here is an llvm ir of a module. It seems that "b1" should be eliminated by dead store elimination. But it did not. Could anyone explain why and how "b1" can be eliminated? Thanks, -Peng %0 = type { [3 x [1 x i32]] } declare %0 @external_fcn3(i32, i32, i32, i32, [3 x [1 x i32]]*) define i32 @f3(i32 %a) readnone { entry: %b1 = alloca [3 x [1 x i32]] %b2 = alloca [3 x

Hey all, Now that we have sign/zero extensions, have people given thought to the elimination of these? There's a paper I downloaded a few years ago called "Effective Sign Extension Elimination" by M. Kawahito, H. Komatsu, and T. Nakatani. I only have a dead tree copy of it, though. But I can share it as much as I can. -bw

On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > Hi all, > > I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. > > If I have some sequence (> 1)

On Fri, 2019-08-30 at 10:03 -0700, Quentin Colombet wrote: > > On Aug 30, 2019, at 8:31 AM, Jesper Antonsson via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > After dead-mi-elimination I'm experiencing a machine verifier > > failure > > at this virtual subregister write: > > > > %5.sub1 = COPY undef

On Thu, Oct 6, 2011 at 2:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: >> Hi all, >> >> There might be a bug in DeadStoreElimination.cpp. This pass eliminates >> stores backwards aggressively in an end BB. It does not check dependencies >> on stores in an end BB though. For example, in this code snippet: >>   ... >> 1.  %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre, >> %entry.for.end_crit_edge ], [ %sum.safe_r42, %for...

Hi Peng, > Here is an llvm ir of a module. It seems that "b1" should be eliminated by dead > store elimination. But it did not. > > Could anyone explain why and how "b1" can be eliminated? > > Thanks, > -Peng > > %0 = type { [3 x [1 x i32]] } > > declare %0 @external_fcn3(i32, i32, i32, i32, [3 x [1 x i32]]*) > > define i32 @f3(i32 %a)

On May 19, 2010, at 3:13 PM, o.j.sivart at gmail.com wrote: >> >> Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead etc. > > I understand that dead code elimination is able to delete

Aye, between all current register allocators the 'AU.addRequiredID(PHIEliminationID);' will cause phi's to be eliminated to copies, but this misses the point of my question. What I am asking, is how does stack know that the value of the variable which the resulting value of the phi is currently allocated at. For instance take the instruction: Machine Basic Block (mbb) 12 reg16666 =

On 20/05/2010, at 8:16 AM, Chris Lattner wrote: > > On May 19, 2010, at 3:13 PM, o.j.sivart at gmail.com wrote: > >>> >>> Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead

On Thu, 4 Jan 2007, Bill Wendling wrote: > Now that we have sign/zero extensions, have people given thought to > the elimination of these? There's a paper I downloaded a few years > ago called "Effective Sign Extension Elimination" by M. Kawahito, H. > Komatsu, and T. Nakatani. Sign extension elimination is most useful in the backend, when targeting processors like

When doing phi elimination, does one have to communicate with the stack space at all? The problem I see is two distinctly different registers may have two distinctly different stack spaces. When these registers are combined in a phi, the values the registers point to needs to be moved, combined, or otherwise taken care of. I understand this is the job of the stack space colorer, but when doing phi

On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: > Hi all, > > There might be a bug in DeadStoreElimination.cpp. This pass eliminates > stores backwards aggressively in an end BB. It does not check dependencies > on stores in an end BB though. For example, in this code snippet: >   ... > 1.  %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre, > %entry.for.end_crit_edge ], [ %sum.safe_r42, %for.body ] > 2.  %ca...

Hi, After dead-mi-elimination I'm experiencing a machine verifier failure at this virtual subregister write: %5.sub1 = COPY undef %11 The machine verifier essentially complains that the rest of the register is undefined (a subregister write implies a "read" of the other parts). So the problem is that dead-mi-elimination has removed the previously existing defines of %5.sub0.

Hi, I have two register classes A and B, where A contains a subset of the registers in B: A = [R0, R1, R2, ... R128] B = [RO, R1, R2, ... R128, T0, T1, T2, ... T128] I am using the Greedy Register Allocator, and I would expect the register allocator to eliminate this copy: %vreg0<def> = COPY %vreg1; B:%vreg0 A:%vreg1 but instead I end up with %R0<def> = COPY %R1 Is there

Hi. Is there any commad for eliminate old kernels from grub instead of edit manually grub.conf and eliminate the files from /boot? Iago. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20051109/36a7fafa/attachment.html>

Hello Chris The general concept is to replace void with {}. Void is a weird type in >> that it is only allowed as the return value of functions and as the type of >> instructions like store. It seems better (though also not particularly >> high priority) to eliminate it to make the type system more consistent. >> > MVT::isVoid and Type::VoidTyID (getVoidTy) have

At the moment, phi elimination happens before register allocation, so there can be no phis between memory locations. Cameron On Oct 5, 2010, at 4:19 PM, Jeff Kunkel wrote: > When doing phi elimination, does one have to communicate with the > stack space at all? The problem I see is two distinctly different > registers may have two distinctly different stack spaces. When these >