Updates in this revision:

• Implement shape detection (so only work on 1D arrays)
• Fix off-by-one error in loop (found when testing on SNAP)
• Fix some review comments
• Rebase to llvm/main instead of fir-dev

LGTM.
Tested locally, works for me!

Updated commit message.

Fix broken test

Removed references to fir-dev issue numbers.

Removed some unnecessary test-lines [testing for variables used nowhere else
and constants used to set up the I/O, where the call itself is not tested]

Update test to MLIR

Add assert for bounds back in, remove if-statment. This puts the code in
the new loop back to how the code was before the loop.

Replace if with assert, as it was in earlier code (before the loop was added)

In D125302#3512417, @shraiysh wrote:

LGTM with comments addressed. Thanks!

Update for review comments

In D125407#3507337, @mehdi_amini wrote:

Just some quick skimming through, I had a few comments, hope this helps! :)

LGTM

I have left my machine to compile that file over night, to see if it's a genuine hang or just "takes a very long time" - if it's not finished by tomorrow morning, I'm definitely calling it a hang. I will report back tomorrow on the result of that.

We did some more digging and it looks like a Clang 13 issue. On AArch64, both Clang 12 and Clang 14 are fine. I believe that @Leporacanthicus was also able to reproduce this with Clang 13 on X86.

LGTM

LGTM. Just one nit-pick, there's a few new tests that test some pretty specific things. Would be nice to have a line or three about what they actually test - e.g "Tests that destructor is not called until after OpenMP section has completed".

Generally looks good to me. Just one nit-pick and one "I don't really understand how this actually produces the correct result" (may be that I'm just missing something!)

Make simd_modifier a unit-attribute and fix formatting

Fix review comments

As this is now squashed into D111051, this review is no longer required.

Squashed the "fixes" commit and the original commit

BUMP.

Update to match changes in dependent commit (+ rebase)

Rebase to latest llvm/main

LGTM

Looks OK to me, but please don't merge until someone else also approves.

LGTM.

Updating according to review comments

LGTM

Trying to get two commits in one arcanist command - may not work

Ah, this definitely would make "random" values for floating point values - in weird ways that are hard to understand!

In D108622#2962282, @jeanPerier wrote:

In D108622#2962219, @Leporacanthicus wrote:

Looks like it's doing what's needed. Is there a follow-on patch to fix the fact that values isn't being passed to the DATE_AND_TIME subroutine?

Do you mean a patch in lowering ?

If so, yes, once this is up streamed, lowering will be updated.

Looks like it's doing what's needed. Is there a follow-on patch to fix the fact that values isn't being passed to the DATE_AND_TIME subroutine?

(Sorry, I thought I'd approved it yesterday, but clearly didn't click the submit button!)

It would seem that your patch may have broken some builds:
https://lab.llvm.org/buildbot/#/builders/175/builds/2077

In D107575#2929026, @Meinersbur wrote:

There seems to be a problem in how import common not finding common.py in a sibling directory.

vsnprintf is named _vsnprintf by Microsoft. According to their docs, it should also be available as vsnprintf with

#include <stdio.h>
#include <stdarg.h>

but even Google test uses

#if GTEST_OS_WINDOWS
# define vsnprintf _vsnprintf
#endif  // GTEST_OS_WINDOWS

Thanks for the updated patch, this seems to work for my simple use-case.

In D105706#2905915, @Meinersbur wrote:

In D105706#2904731, @Leporacanthicus wrote:

Calling collapseLoops in convertOmpWsLoop sets the AfterIP to the wrong place - this causes incorrect LLVM-IR to be generated - an empty block and one with two unconditional branches in a row, like this:

Where does AfterIP point to and where do you think it should point to after collapseLoops? Should the result of collapseLoops be changed or is it an issue of how convertOmpWsLoop uses CanonicalLoopInfo?

Sorry for the rather lengthy comment. I am not sure if I'm expecting the wrong thing, I'm doing something wrong, or this patch is incorrect, so I'll try to put as much information into this comment as I can.
Any suggestions, hints or similar would be welcome. I fully expect some of my workarounds and fixes to be called out as wrong - and I don't mean my global variable, which is clearly just a workaround for not understanding how to get the correct value out of where it is known.

LGTM

Some minor nit-picks, but nothing wrong - I tested this with some of my fortran code that I've been using for other testing, and it seems to work.

In D103177#2791916, @klausler wrote:

I still don't understand why you have to mess with f18.cpp. What would break if you left it alone?

Removed wrong comment endings.

@Meinersbur Is there anything else I need to do here?

Remove the code that add in modifiers to the scheduling type,
as per review comments.

Rebase and fixed comment style.

Patch doesn't apply because it is relying on my previous patch. Doh!

LGTM

Adding MLIR to LLVM-IR tests. The tests are very basic, just checking that
the correct runtime functions are called.

Updates based on review comments:

• Fix style using PascalCase rather than camelCase.
• Add Doxygen comment for parameter.
• Change comment style for constants.
• Remove useless error output - there was no way to get to that error.
• Use llvm_unreachable instead of assert(0).

Will do some minor fixes tomorrow, thanks for the feedback!

LGTM

LGTM

LGTM.

In D97393#2666954, @Meinersbur wrote:

Could you add the following to the unittest?

Builder.restoreIP(EndIP);
Builder.CreateRetVoid();
OMPBuilder.finalize();
EXPECT_FALSE(verifyModule(*M, &errs()));

I checks whether the IR is internally consistent.

Updates as per review comments: