Page MenuHomePhabricator

Prazek (Piotr Padlewski)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 21 2015, 5:19 PM (356 w, 5 d)

Recent Activity

Oct 25 2021

Prazek added a comment to D112016: [IR] Introduce load assume operand bundle.

happy to change the name if there's a better alternative

To bikeshed a bit, how about "load_eq"? Meaning, "a load of op1 is equal to op2".

Oct 25 2021, 6:50 AM · Restricted Project

Sep 15 2021

Prazek abandoned D29064: [MemorySSA] Add invariant.group handling.

I implemented this properly with Arthur in https://reviews.llvm.org/D109134

Sep 15 2021, 12:37 PM

Sep 14 2021

Prazek added a comment to D109548: Make llvm.launder.invariant.group writeonly.

volatile reads are considered write effects, IIRC: https://godbolt.org/z/73Tqjj4rc

Sep 14 2021, 1:11 AM · Restricted Project

Sep 13 2021

Prazek added a comment to D109548: Make llvm.launder.invariant.group writeonly.

@Prazek writeonly only says that no memory is read, it does not determine which location is actually written. launder.invariant.groupdoes not read or write the pointer operands (it is inaccessiblememonly), it "writes" some inaccessible location to avoid code motion optimizations. To perform DSE, we need to know the location being written.

If a writeonly function is called multiple times, can it can only write a constant to a constant location or the argument? To be able to write to different locations across calls or write a different value, it'd have to do read memory to be able to determine when to do something different right? e.g. a global counter to write a different on multiple invocations.
So could we prove that it does the exact same thing across multiple back-to-back invocations given the same argument? Or could we consider this intrinsic to not really read to memory but still not produce the same results upon back-to-back invocations with the same argument?

"write a constant to a constant location" is only true if you have no arguments. Basically, constants + arguments is what you have to decide what and where to write. Same arguments + write only => same effect.

[EDIT] On second though. We might have intrinsics that make this more complicated as they allow you to get input without reading things. I'm not 100% sure but the "read thread ID" intrinsics on GPUs might fall into that category.

Basically can we optimize

%b = @llvm.writeonly(%a)
%c = @llvm.writeonly(%a)

to just

%b = @llvm.writeonly(%a)

and RAUW %c with %b

I'd argue that we can't without further information -- the write may be volatile.

Sep 13 2021, 7:20 AM · Restricted Project

Sep 10 2021

Prazek requested changes to D109548: Make llvm.launder.invariant.group writeonly.

Actually, as Krzysztof Pszeniczny pointed out offline, I think we can't mark it as writeonly, because it would let optimizer to optimize:

Sep 10 2021, 5:10 AM · Restricted Project
Prazek added inline comments to D109548: Make llvm.launder.invariant.group writeonly.
Sep 10 2021, 2:44 AM · Restricted Project
Prazek added a comment to D109548: Make llvm.launder.invariant.group writeonly.

Do you have any examples of where this is relevant in practice?

The change looks sound to me, but should probably apply to all intrinsics that exist to model control dependence, i.e. assume, noalias.scope.decl, annotation etc.

Sep 10 2021, 2:21 AM · Restricted Project
Prazek accepted D109548: Make llvm.launder.invariant.group writeonly.

This seems to be valid!
Can any func attr expert can comment on what sort of optimizations/reordering this enables? I am a bit worried we might be missing something.

Sep 10 2021, 2:19 AM · Restricted Project

Sep 3 2021

Prazek added inline comments to D109134: [MemorySSA] Support invariant.group metadata.
Sep 3 2021, 3:50 AM · Restricted Project

Sep 2 2021

Prazek accepted D109134: [MemorySSA] Support invariant.group metadata.

Great! We will need to take a look at what NewGVN missed and understand if this is NewGVN fault, or are we missing something on MSSA site.

Sep 2 2021, 5:53 AM · Restricted Project

Aug 28 2021

Prazek accepted D108734: [InstCombine] Remove invariant group intrinsincs when comparing against null.

LGTM!

Aug 28 2021, 3:59 AM · Restricted Project
Prazek added a comment to D108837: [SimplifyCFG] Ignore free instructions when computing cost for folding branch to common dest.

This looks resonable. BTW are {launder,strip}.inariant.group intrinsics considered to be free now? I remember fixing this in InlineCost, but this seems to be other cost heuristic. They totally should be considered free.

Aug 28 2021, 3:53 AM · Restricted Project

Aug 27 2021

Prazek added a comment to D108734: [InstCombine] Remove invariant group intrinsincs when comparing against null.

Could you also update the description and title?

Aug 27 2021, 3:00 AM · Restricted Project
Prazek accepted D108734: [InstCombine] Remove invariant group intrinsincs when comparing against null.

LGTM! Great work with looking for regressions like that.

Aug 27 2021, 2:14 AM · Restricted Project

Aug 26 2021

Prazek added a comment to D108734: [InstCombine] Remove invariant group intrinsincs when comparing against null.

Just for the record (discussed offline): if the problem is comparisons of launder/strip(%p) with null, then for this specific case we could I think replace it with comparison of %p and null, as null does does not have any "virtual" information (similarly how we already optimzie launder/strip(null) to null

Aug 26 2021, 5:43 AM · Restricted Project
Prazek requested changes to D108734: [InstCombine] Remove invariant group intrinsincs when comparing against null.

Lets talk offline about the specific case to get it right. The model is pretty brittle in those areas, so we have to be sure the transformations are legal

Aug 26 2021, 5:30 AM · Restricted Project

Jul 25 2021

Prazek added a comment to D106017: [InstCombine] Look through invariant group intrinsics when removing malloc.

Sorry for late reply. Although I don't have experience in this pass, it looks good!

Jul 25 2021, 9:45 AM · Restricted Project

May 17 2021

Prazek added inline comments to D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands.
May 17 2021, 6:30 AM · Restricted Project

May 11 2021

Prazek requested changes to D99784: [LICM] Hoist loads with invariant.group metadata.

I had some time to look into it now, sorry that I missed it on first revision.
If I understand the LICM code correctly, it needs to drop all the instruction metadata when hoisting instruction that will not be executed unconditionally. This means that code like:
https://godbolt.org/z/bjP64PbhY

May 11 2021, 6:14 AM · Restricted Project

May 2 2021

Prazek added inline comments to D101553: [Loads] Skip non load/store instructions when finding available load.
May 2 2021, 6:22 AM · Restricted Project

Apr 28 2021

Prazek added a comment to D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands.

Out of curiosity: have you seen this pattern happening in the wild with -fstrict-vtable-pointers?

Yes, it was causing a major size regression in one specific file (with rtti). I've managed to reduce it down to

struct A {
  int i;
  virtual void f();
  A(): i(4) {}
};

const A g;

int foo() {
  const A* a = &g;
  return a->i;
}

$ ./build/rel/bin/clang++ /tmp/a.cc -o - -S -emit-llvm -O2 -fstrict-vtable-pointers

%struct.A = type <{ i32 (...)**, i32, [4 x i8] }>

@_ZL1g = internal constant %struct.A <{ i32 (...)** bitcast (i8** getelementptr inbounds ({ [3 x i8*] }, { [3 x i8*] }* @_ZTV1A, i32 0, inrange i32 0, i32 2) to i32 (...)**), i32 4, [4 x i8] zeroinitializer }>, align 8
@_ZTV1A = external dso_local unnamed_addr constant { [3 x i8*] }, align 8
@llvm.global_ctors = appending global [0 x { i32, void ()*, i8* }] zeroinitializer

; Function Attrs: nofree nosync nounwind readnone uwtable willreturn mustprogress
define dso_local i32 @_Z8hahahahav() local_unnamed_addr #0 {
entry:
  %0 = tail call i8* @llvm.strip.invariant.group.p0i8(i8* bitcast (%struct.A* @_ZL1g to i8*))
  %i = getelementptr inbounds i8, i8* %0, i64 8
  %1 = bitcast i8* %i to i32*
  %2 = load i32, i32* %1, align 8, !tbaa !6
  ret i32 %2
}

$ ./build/rel/bin/clang++ /tmp/a.cc -o - -S -emit-llvm -O2

; Function Attrs: nofree norecurse nosync nounwind readnone uwtable willreturn mustprogress
define dso_local i32 @_Z8hahahahav() local_unnamed_addr #0 {
entry:
  ret i32 4
}
Apr 28 2021, 3:00 AM · Restricted Project
Prazek added a comment to D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands.

looks like the strip is coming from CodeGenFunction::EmitLValueForField():

if (auto *ClassDef = dyn_cast<CXXRecordDecl>(rec)) {
  if (CGM.getCodeGenOpts().StrictVTablePointers &&
      ClassDef->isDynamicClass()) {
    // Getting to any field of dynamic object requires stripping dynamic
    // information provided by invariant.group.  This is because accessing
    // fields may leak the real address of dynamic object, which could result
    // in miscompilation when leaked pointer would be compared.
    auto *stripped = Builder.CreateStripInvariantGroup(addr.getPointer());
    addr = Address(stripped, addr.getAlignment());
  }
}

is this actually true?

Apr 28 2021, 2:51 AM · Restricted Project

Apr 27 2021

Prazek added a comment to D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands.

Out of curiosity: have you seen this pattern happening in the wild with -fstrict-vtable-pointers?

Apr 27 2021, 1:48 AM · Restricted Project
Prazek added a comment to D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands.

I think the recursion is unfortunate there. How about something like

static Constant *ConstructLoadOperandConstant(Value *Op) {
  SmallVector<Value*, 16> Worklist;
  
  OpStack.emplace_back(Op);
  for(int I = 0; I != OpStack.size(); ++I) {
    Value* Op = OpStack.back();
    
    if (isa<Constant>(Op))
      break; // YAY!

    if (auto *BC = dyn_cast<BitCastOperator>(Op))
      OpStack.emplace_back(BC->getOperand(0)); // Recurse.

    if (auto *GEP = dyn_cast<GEPOperator>(Op)) {
      if (all_of(ArrayRef<Value*>(GEP->operands()).drop_front(),
          [](Value*Op) { return isa<Constant>(Op); }))
        OpStack.emplace_back(GEP->getOperand(0)); // Recurse.
    }

    if (auto *II = dyn_cast<IntrinsicInst>(Op)) {
      if (II->getIntrinsicID() == Intrinsic::strip_invariant_group ||
          II->getIntrinsicID() == Intrinsic::launder_invariant_group)
        OpStack.emplace_back(II->getOperand(0)); // Recurse.
    }
    
    return nullptr; // Can't look past this instruction. Give up.
  }
  
  // Alright! Reconstruct this chain as constant expressions.
  Constant* NewOp = cast<Constant>(Worklist.pop_back_val());
  while(!OpStack.empty()) {
    Value* Op = OpStack.pop_back_val();

    if (isa<BitCastOperator>(Op))
      NewOp = ConstantExpr::getBitCast(NewOp, Op->getType());

    if (auto *GEP = dyn_cast<GEPOperator>(Op)) {
      SmallVector<Constant *> Idxs;
      Idxs.reserve(GEP->getNumOperands() - 1);
      for (unsigned I = 1, E = GEP->getNumOperands(); I != E; ++I)
        Idxs.push_back(cast<Constant>(GEP->getOperand(I));
      return ConstantExpr::getGetElementPtr(GEP->getSourceElementType(), NewOp,
                                            Idxs, GEP->isInBounds(),
                                            GEP->getInRangeIndex());
    }

    if (auto *II = dyn_cast<IntrinsicInst>(Op)) {
      if (II->getIntrinsicID() == Intrinsic::strip_invariant_group ||
          II->getIntrinsicID() == Intrinsic::launder_invariant_group)
        NewOp = ConstantExpr::getBitCast(NewOp, Op->getType());  
    }
    
    llvm_unreachable("Instruction handled in first loop but not here?");
  }
}
  
return NewOp;
Apr 27 2021, 1:47 AM · Restricted Project
Prazek added a reviewer for D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands: Prazek.
Apr 27 2021, 1:36 AM · Restricted Project

Sep 30 2019

Prazek added a comment to D68236: Handle llvm.launder.invariant.group in msan..

+1, strip.invariant.group probably needs the same handling. Thanks for fixing!

Sep 30 2019, 11:49 PM · Restricted Project

Jul 2 2019

Prazek added inline comments to D54815: [ThinLTO] Add summary entries for index-based WPD.
Jul 2 2019, 1:33 PM · Restricted Project
Prazek added inline comments to D54815: [ThinLTO] Add summary entries for index-based WPD.
Jul 2 2019, 12:51 PM · Restricted Project

Jun 14 2019

Prazek added inline comments to D53295: Mark store and load of block invoke function as invariant.group.
Jun 14 2019, 5:40 PM

Nov 27 2018

Prazek added a comment to D45151: [LICM] Hoisting invariant.group loads.

I'm sorry I can't be more decisive here since I wasn't deeply involved with the devirtualization work early on and so lack a lot of context. The general direction here seems fine to me -- given that we use metadata to express a large range of things, it seems ok to have metadata specific MD dropping policies. However, given that Hal originally objected to this, we should make sure he is on board.

I understand the motivation, thanks. The problem here is that, while we might want to avoid hoisting so that we don't strip the metadata, that only is better if we happen to inline into a function that then provides a concrete type. Otherwise, we should have hoisted. How about this: Add a parameter to LICM to control this choice: We can choose not to hoist during the early runs on LICM (which happen during inlining), and then hoist later (during the LICM invocation that runs after loop unrolling).

Nov 27 2018, 6:08 AM · Restricted Project

Sep 11 2018

Prazek accepted D51936: Fix a use-after-RAUW bug in large GEP splitting.

LGTM, but please wait for Javed to review

Sep 11 2018, 12:25 PM

Sep 7 2018

Prazek committed rL341725: Set cost of invariant group intrinsics to 0.
Set cost of invariant group intrinsics to 0
Sep 7 2018, 3:31 PM
Prazek closed D51814: Set cost of invariant group intrinsics to 0.
Sep 7 2018, 3:31 PM
Prazek created D51814: Set cost of invariant group intrinsics to 0.
Sep 7 2018, 1:57 PM

Aug 14 2018

Prazek added a comment to D45151: [LICM] Hoisting invariant.group loads.

Can we spec !invariant.group in a way that lets us always keep the metadata when hoisting? Right now it isn't clear what happens if its contract is violated, i.e. what the behavior of this program is:

store i32 0, i32* %ptr, !invariant.group !0
%x = load i32, i32* %ptr, !invariant.group !0
store i32 1, i32* %ptr, !invariant.group !0
%y = load i32, i32* %ptr, !invariant.group !0

though it seems like you're assuming the *load* has UB? Can we instead say that the second store has UB? That way we should be able to hoist the load instruction without dropping the metadata.

Aug 14 2018, 3:40 PM · Restricted Project

Aug 13 2018

Prazek added inline comments to D45151: [LICM] Hoisting invariant.group loads.
Aug 13 2018, 4:00 PM · Restricted Project

Jul 16 2018

Prazek added a reviewer for D45151: [LICM] Hoisting invariant.group loads: rsmith.
Jul 16 2018, 9:36 PM · Restricted Project
Prazek added a comment to D45151: [LICM] Hoisting invariant.group loads.

friendly ping

Jul 16 2018, 9:04 AM · Restricted Project

Jul 12 2018

Prazek committed rL336963: Simplify recursive launder.invariant.group and strip.
Simplify recursive launder.invariant.group and strip
Jul 12 2018, 5:00 PM
Prazek closed D47423: Simplify recursive launder.invariant.group and strip.
Jul 12 2018, 5:00 PM

Jul 10 2018

Prazek added inline comments to D47423: Simplify recursive launder.invariant.group and strip.
Jul 10 2018, 5:32 PM
Prazek added inline comments to D47423: Simplify recursive launder.invariant.group and strip.
Jul 10 2018, 10:36 AM

Jul 3 2018

Prazek added inline comments to D47423: Simplify recursive launder.invariant.group and strip.
Jul 3 2018, 10:28 AM

Jul 2 2018

Prazek committed rL336137: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
[CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers
Jul 2 2018, 12:26 PM
Prazek committed rC336137: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
[CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers
Jul 2 2018, 12:26 PM
Prazek closed D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Jul 2 2018, 12:26 PM

Jul 1 2018

Prazek added inline comments to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Jul 1 2018, 10:35 PM
Prazek updated the diff for D47423: Simplify recursive launder.invariant.group and strip.

fixed addrspace cast

Jul 1 2018, 10:33 PM
Prazek added inline comments to D47423: Simplify recursive launder.invariant.group and strip.
Jul 1 2018, 10:21 PM
Prazek committed rL336073: Implement strip.invariant.group.
Implement strip.invariant.group
Jul 1 2018, 9:55 PM
Prazek closed D47103: Implement strip.invariant.group.
Jul 1 2018, 9:54 PM

Jun 16 2018

Prazek added inline comments to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Jun 16 2018, 10:56 AM

Jun 15 2018

Prazek added inline comments to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Jun 15 2018, 3:38 PM
Prazek added inline comments to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Jun 15 2018, 3:37 PM
Prazek updated the diff for D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.

Refactor

Jun 15 2018, 3:36 PM
Prazek added inline comments to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Jun 15 2018, 3:33 PM

Jun 13 2018

Prazek updated the diff for D45151: [LICM] Hoisting invariant.group loads.
  • Fixed comments

@hfinkel is my response resonable?

Jun 13 2018, 7:21 AM · Restricted Project
Prazek committed rL334600: Add -fforce-emit-vtables.
Add -fforce-emit-vtables
Jun 13 2018, 7:00 AM
Prazek committed rC334600: Add -fforce-emit-vtables.
Add -fforce-emit-vtables
Jun 13 2018, 7:00 AM
Prazek closed D47108: [CodeGenCXX] Add -fforce-emit-vtables.
Jun 13 2018, 7:00 AM
Prazek edited reviewers for D47103: Implement strip.invariant.group, added: davide; removed: rjmccall.
Jun 13 2018, 6:43 AM
Prazek added a comment to D47103: Implement strip.invariant.group.

Friendly ping @hfinkel @rsmith

Jun 13 2018, 6:43 AM

Jun 11 2018

Prazek updated the diff for D47108: [CodeGenCXX] Add -fforce-emit-vtables.
  • Fixed templates
Jun 11 2018, 6:24 AM
Prazek updated the diff for D47423: Simplify recursive launder.invariant.group and strip.

updated test

Jun 11 2018, 4:21 AM
Prazek updated the diff for D47423: Simplify recursive launder.invariant.group and strip.

unreachable

Jun 11 2018, 4:02 AM

Jun 2 2018

Prazek added a comment to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.

@rjmccall @rsmith friendly ping

Jun 2 2018, 1:51 PM
Prazek added a comment to D47103: Implement strip.invariant.group.

friendly ping

Jun 2 2018, 1:45 PM
Prazek added a comment to D45151: [LICM] Hoisting invariant.group loads.

s/loop unrolling/loop peeling/
I will had to take a look at this at some time, but from what I've heard the state of loop peeling in LLVM is not very sofisticated, and implementing the logic that I propose might be a little hard.

Jun 2 2018, 8:37 AM · Restricted Project
Prazek added a comment to D45151: [LICM] Hoisting invariant.group loads.

You say that you don't yet know if this is profitable yet. Do you have reason to believe that it might not be profitable (e.g., some example where it seems like we might want to constrain the behavior)? We almost never favor keeping metadata over doing other transformations, so I think it's worth being explicit about our reasoning here. Just saying "I don't know yet" is probably not sufficient, as we could say that about nearly all metadata, and in that case, change the default logic.

Jun 2 2018, 8:28 AM · Restricted Project

May 29 2018

Prazek added a comment to D47214: [InstCombine] Replace bcmp/bcopy with memcmp/memmove.

And two facts..

  1. LLVM already replaces bzero with memset
  2. There are many source codes related to networking which uses bcopy, bcmp.

So I dont think this patch is totally useless.

Maybe @Prazek can do review of this patch for me?

May 29 2018, 6:31 AM

May 28 2018

Prazek updated the diff for D47108: [CodeGenCXX] Add -fforce-emit-vtables.

fixed test

May 28 2018, 2:46 PM

May 27 2018

Prazek updated the diff for D47108: [CodeGenCXX] Add -fforce-emit-vtables.

small update

May 27 2018, 11:39 AM
Prazek updated the diff for D47108: [CodeGenCXX] Add -fforce-emit-vtables.

Fixed missing vtable commponents

May 27 2018, 11:18 AM
Prazek updated the diff for D47423: Simplify recursive launder.invariant.group and strip.

fixed nit

May 27 2018, 9:56 AM
Prazek created D47423: Simplify recursive launder.invariant.group and strip.
May 27 2018, 6:28 AM
Prazek updated the diff for D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.

one more test

May 27 2018, 5:11 AM
Prazek updated the diff for D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
Added launder when going from possiblyNotDynamic to possiblyDynamic
emitting strip for pointer -> int only if poitner is possiblyDynamic
May 27 2018, 5:10 AM
Prazek added a reviewer for D45151: [LICM] Hoisting invariant.group loads: hfinkel.

Can someone with experience in Loop passes take a look at this?

May 27 2018, 4:49 AM · Restricted Project

May 25 2018

Prazek added inline comments to D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
May 25 2018, 5:44 PM
Prazek added a comment to D45150: Less conservative LoopSafetyInfo for headers.

OK, so it seems that at least the tests in the second patch passes without this patch, so I am fine with committing it without this one for one (also Philip if you could take a look at that patch I would be grateful)
I am worried about cases, where the first instruction does not throw, but it we can't hoist it (e.g. it depends on the loop phi) and after that, there is an instruction that can be hoisted.

May 25 2018, 4:26 AM · Restricted Project

May 23 2018

Prazek added inline comments to D47103: Implement strip.invariant.group.
May 23 2018, 4:17 PM
Prazek updated the diff for D47103: Implement strip.invariant.group.

Slitted commit into defining and using intrinsic

May 23 2018, 4:17 PM
Prazek created D47299: [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointers.
May 23 2018, 4:13 PM
Prazek committed rL333070: Fix aliasing of launder.invariant.group.
Fix aliasing of launder.invariant.group
May 23 2018, 2:20 AM
Prazek closed D47088: Fix aliasing of launder.invariant.group.
May 23 2018, 2:20 AM
Prazek added a comment to D47108: [CodeGenCXX] Add -fforce-emit-vtables.

I thought we already had places in Sema that marked inline virtual methods as used, instantiated templates, etc. for devirtualization purposes when optimization was enabled. Did we rip that out?

I only recall the emitting available_externally vtables opportunistically, that is emitting it only if all the inline virtual functions are present (and they are not hidden).
(https://reviews.llvm.org/D33437)

May 23 2018, 1:16 AM

May 22 2018

Prazek updated the diff for D47088: Fix aliasing of launder.invariant.group.
  • Add more comments
May 22 2018, 5:57 PM
Prazek added a comment to D47108: [CodeGenCXX] Add -fforce-emit-vtables.

@rjmccall do you have any thoughts on the best way to solve it?

May 22 2018, 5:42 AM
Prazek retitled D47108: [CodeGenCXX] Add -fforce-emit-vtables from Add -fforce-emit-vtables to [CodeGenCXX] Add -fforce-emit-vtables.
May 22 2018, 5:42 AM

May 19 2018

Prazek updated the diff for D47103: Implement strip.invariant.group.

rebase

May 19 2018, 5:07 PM
Prazek updated the diff for D47088: Fix aliasing of launder.invariant.group.

fix name

May 19 2018, 5:01 PM
Prazek updated the diff for D47103: Implement strip.invariant.group.

After rebasing

May 19 2018, 4:47 PM
Prazek added inline comments to D47088: Fix aliasing of launder.invariant.group.
May 19 2018, 4:34 PM
Prazek updated the diff for D47088: Fix aliasing of launder.invariant.group.
  • small refactor
May 19 2018, 4:33 PM
Prazek added inline comments to D47088: Fix aliasing of launder.invariant.group.
May 19 2018, 4:03 PM
Prazek updated the diff for D47103: Implement strip.invariant.group.

Changed comments

May 19 2018, 3:55 PM
Prazek updated the diff for D47103: Implement strip.invariant.group.

introduced mayBeDynamicClass and added more tests

May 19 2018, 3:11 PM
Prazek retitled D47108: [CodeGenCXX] Add -fforce-emit-vtables from Add -fforce-emit-vtable to Add -fforce-emit-vtables.
May 19 2018, 1:09 PM
Prazek updated the diff for D47108: [CodeGenCXX] Add -fforce-emit-vtables.

Fixed flag passing

May 19 2018, 1:08 PM
Prazek updated the diff for D47108: [CodeGenCXX] Add -fforce-emit-vtables.

Fixed comment

May 19 2018, 12:16 PM