I agree that the size of a block should not be larger than the half of memory size.

• Support floating points, pointers, aggregate types, add tests for those types

• Use FreezeOperator inside Freeze_match

• Rebase
• Add more tests to freeze.ll
• Define FreezeOperator

In D29011#1707278, @lebedev.ri wrote:

Should you add llvm::Freeze here by inheriting from UnaryOperator to make isa<Freeze>(Op) possible?

• Support freeze constexpr
• Make freeze's type checking consistent with LangRef.

should there be a constantexpr freeze

Updated the patch so UnaryOperator is used for Instruction::Freeze op.
Currently I see an error from Phabricator while uploading a new diff:

Unhandled Exception ("PhabricatorFileUploadException")	
Unable to write file: failed to write to temporary directory.

I'll retry uploading it later.

Rebase to trunk@369887 (August 26th, 2019)

Rebase to trunk@369887 (August 26th, 2019)

Rebase to trunk@369887 (August 26th, 2019)

Sorry, I was pretty busy last week.
@xbolva00 Rebased

One mode of reasoning that could invalidate this example is that p *could have been* something other than 2^64-4 which would invoke UB. This UB would both let us pretend that foo does not escape p, and also print 2^64-4 even though p was not 2^64-4 in the execution we chose. This seems a bit subtle though, and I'm not entirely sure this is sound reasoning.

In the example, the original pointer (%addr = load %struct.zot*, %struct.zot** %loc, align 8) is not dereference directly and the use case I am looking at is tagged pointers, where the inttoptr(and(ptrtoint(), C) roundtrip is required to get a valid pointer. So the original pointer might not be dereferenceable directly, but logically (ignoring the bits irrelevant for the pointer value) it should still point to the same object. Does that make sense to you?

In D59065#1448677, @sanjoy wrote:

In D59065#1448178, @hfinkel wrote:

I am also not entirely sure how control dependencies could add new underlying objects with this patch

Please read this https://bugs.llvm.org/show_bug.cgi?id=34548

I *think* that this is okay if the ptrtoint and the and have only one user, and they're in the same basic block, and there's nothing that can throw, etc. in between?

I'm not sure about this. You could have:

int32* ptr0 = malloc(4);
int32* ptr1 = malloc(4);

if (ptr0+1 != ptr1) return;

int32* ptr = (int*)(int64)(ptr0+1);

in which ptr would alias ptr1. But if you transform ptr to ptr0+1 then it would not alias ptr1. That IR ^ could have resulted from:

int32* ptr0 = malloc(4);
int32* ptr1 = malloc(4);

if (ptr0+1 != ptr1) return;

int64 ptr0_i = (int64)(ptr0+1);
int64 ptr1_i = (int64)(ptr1);

int32* ptr = (int*)ptr1_i;

Thanks! :)
I don't have commit access; if you don't mind, could you commit this patch instead please?

I couldn't find ready for review option from anywhere :( 'Add Action...' dropdown menu contains Plan Changes and Abandon Revision only.

Removes eraseValue() calls

Abandon this patch; will a new patch be uploaded later

Hello all, I sincerely thank you for your comments. I'll apply the comments & re-upload the patch.

https://reviews.llvm.org/D56601 shows how CaptureTracker can be enhanced with llvm.psub.

I think we need to check whether shl/mul has nsw flag.

Hello all,

In D50295#1188969, @hfinkel wrote:

In D50295#1188623, @aqjune wrote:

store i8* %p, i8** %q
%p2 = load i8*, i8** %q ; p2 is p

If we have MemorySSA, this can be resolved in constant time. I believe BasicAliasAnalysis can get benefit this, hence supporting partially flow sensitive analysis.

I read that in the comment ;) -- but why? Shouldn't all such cases be simplified by GVN (etc.) into a form where GetUnderlyingObjects, as is, can reason about them?

Thanks for the comments!

• Address comments
• Update the title
• Add a new test that deals with load volatile

I think it depends on what shl i32 %x, undef is - undef can be concretized into an integer larger than 31, and according to https://llvm.org/docs/LangRef.html#id134 , it is poison, so conversion like the one in shuffle_select.ll may be invalid.
Defining shl with large second operand as poison explains another kind of optimizations, IMHO: For example, InstCombine optimizes (C2 << X) << C1 into (C2 << C1) << X. Defining shl with large shift as undef does not explain this optimimzation - If C1 = 4, C2 = 1 and X = 33, source is (1 << 33) << 4 = undef << 4 = (undef with low 4 bits zero), but after optimization it is (1 << 4) << 33 = undef. If large shift yields poison, this is explained, because poison << 4 = poison.

Yes, you can commit this patch.

• Move definition of operator<< to AliasAnalysis.cpp
• Update format of MemoryDef print

Comments applied :)

• Define << operator for AliasResult & let AliasAnalysisEvaluator.cpp use it as well
• Update printing format of MemoryDef so it prints optimized def as well

Rebased to svn commit 331585

Rebased to svn commit 331586

Rebased to svn commit 331585

Could someone have a try to apply this patch? I just checked out llvm from SVN, tried patch -p0 -i ../patch.file, and it worked well.

Rebased to svn commit 308173

Rebased to svn commit 308173

Rebased to svn commit 308173

Rebased to svn commit 308173

Rebased to svn commit 308173

I apologize for my mistake. I updated the diff and checked that it works with patch -p0 -i diff.patch

Hello, how can I commit this patch to SVN? I don't think I have commit access to SVN. :( If someone applies this patch instead of me it would be a great help. (I wrote a comment here according to the policy written in 'Commiting a change', http://llvm.org/docs/Phabricator.html )

Hello, I don't have commit access. Could someone commit this patch instead? Thanks.

@chenwj Yes, these tests failed in absence of my patch.

I added 4 tests, and checked that make check-llvm works well.

@skatkov Well, the assemblies also included leal with r13 register as well. :)

102     leal    8(%r14), %eax

->

102     leal    8(%r13), %eax

The performance gap may be due to the instruction, but I'm not sure. (actually, converting r14 to r13 increased performance in this case, but I have no idea what's happening inside CPU..)

We report our observation regarding this issue.
We observed 10% speed up for the Queens benchmark in Nightly Test by simply swapping r13 and r14.

• Add FindNextSuccessorBlock
• Minor modifications

NeedFreeze is set to true in this patch, but it can have different value in upcoming patch (https://reviews.llvm.org/D29016).

@filcab Thanks for your comments.

• Compute reachable terminators in advance so it does not traverse same basic block multiple times
• Let branchs with constant condition be treated well

• Move IRBuilder::CreateFreezeAtDef from https://reviews.llvm.org/D29011

• Move isGuaranteedNotToBeUndefOrPoison from https://reviews.llvm.org/D29011

• Move isGuaranteedNotToBeUndefOrPoison to https://reviews.llvm.org/D29013
• Move CreateFreezeAtDef to https://reviews.llvm.org/D29015
• Add a test to unittest/unittests/IR/VerifierTest.cpp
• Add type checking to BitcodeReader.cpp

• Modify typos, add more comments (including TODOs)
• Add tests for parsing error
• Moved test/Bitcode/freeze.ll to test/Bitcode/compatibility.ll.

• FastISel for FREEZE added.
• Updated description of FREEZE.

• Add llvm-c test (test/Bindings/llvm-c/freeze.ll)
• Update tools/llvm-c-test/echo.cpp so it can deal with Freeze instruction.