I added a test case and also an explanation in the commit message on when we can hit this problem.

Added test case and fixed commit message.

Closed by commit rL221550 (authored by @dpeixott).

LGTM

Closed by commit rL220423 (authored by @dpeixott).

In D5762#10, @jdoerfert wrote:

In D5762#9, @dpeixott wrote:

This looks like a nice cleanup to me. I think centralizing the available options for polly makes sense. The major downside in my opinion is that we now have a bunch of global variables. Previously you could look at a command line option that is declared static (without external storage) and know it is only used in that file. Now we are exposing these all as global variables.

That is actually one of the reasons I came up with this patch. I want the options to be available to other LLVM pasess/projects, thus I have to expose them somehow. While I agree that global variables are not the best solution to this problem it is/was the easiest solution to allow me to configure Polly from within another project. Do you think we should wait/look for a different solution without the globals?

This patch makes me nervous because I don't see why it is obviously safe to always promote to the next size without changing semantics. For example, with this loop:

This looks like a nice cleanup to me. I think centralizing the available options for polly makes sense. The major downside in my opinion is that we now have a bunch of global variables. Previously you could look at a command line option that is declared static (without external storage) and know it is only used in that file. Now we are exposing these all as global variables.

Needs test case. Otherwise LGTM.

LGTM with small test case demonstrating the command line option is respected.

LGTM. Could also fold the alignment setting into the creation.

Closed by commit rL218525 (authored by @dpeixott).

ping

Closed by commit rL218387 (authored by @dpeixott).

ping

ping

Updated test case to a simplified loop so that is easier to see why it causes a failure.

In D5227#10, @jdoerfert wrote:

In D5227#7, @dpeixott wrote:

As far as I know detailed mod-ref-behaviour is currently only returned in the case of intrinsic functions. These functions are defined with the appropriate values and tablegen generates some code to return the correct values. You could use an intrinsic function in your test (e.g. llvm.prefetch).

Unfortunatly I cannot export the "onlyReadsArgumentPointees" of llvm.prefetch to IR... it gets overaproximated to "onlyReadsMemory" for now.

Needs a test case to demonstrate the omission of the guard bb. Otherwise, LGTM.

Closed by commit rL217463 (authored by @dpeixott).

As far as I know detailed mod-ref-behaviour is currently only returned in the case of intrinsic functions. These functions are defined with the appropriate values and tablegen generates some code to return the correct values. You could use an intrinsic function in your test (e.g. llvm.prefetch).

Minor typo. Otherwise the patch looks reasonable to me.

Closed by commit rL213387 (authored by @dpeixott).

For completeness I would add one more test for loading a smaller constant to an x register to show that we generate a 64-bit entry in the constant pool even if the value does not require the full 64-bits. You don't need another review for that change.

Thanks, this is looking much better. I had one minor suggestion and a question about the APInt usage.

Thanks for the patch. Overall I like the direction you are going. Please see specific comments below.

It's not clear to me how this change improves the test. Rather than just renaming, I think it would be better to

LGTM.

Minor cleanup, otherwise LGTM.

Adding llvm-commits to CC.

Some minor c++11 suggestions. LGTM with those changes.

LGTM with a suitable commit message explaining why we want to split out the implementation.

Adding llvm-commits to CC.

Overall this looks good to me, but I think we should split this into two commits: 1 factoring commit that moves the constant pools to a place that can be accessed by both AArch64 and ARM backends, and a second commit to implement the ldr= psuedo for AArch64.