This is an archive of the discontinued LLVM Phabricator instance.

[flang] Initial lowering for empty program
ClosedPublic

Authored by clementval on Jan 27 2022, 11:27 PM.

Details

Summary

This patch enable lowering from Fortran to FIR for a basic empty
program. It brings all the infrastructure needed for that. As discussed
previously, this is the first patch for lowering and follow up patches
should be smaller.

With this patch we can lower the following code:

program basic
end program

To a the FIR equivalent:

func @_QQmain() {
  return
}

Follow up patch will add lowering of more complex constructs.

Diff Detail

Event Timeline

clementval created this revision.Jan 27 2022, 11:27 PM
Herald added a project: Restricted Project. · View Herald Transcript
clementval requested review of this revision.Jan 27 2022, 11:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2022, 11:27 PM
rovka added a subscriber: rovka.Jan 28 2022, 2:17 AM

Yaay, it's great to see this patch! :)
I think it's a bit large though, maybe we can remove some things that aren't strictly necessary to make the test pass? That would make both this patch and future patches (where things are actually useed) easier to review.

flang/include/flang/Lower/CallInterface.h
81
82
116

Nit: missing ).
Also, I can't really guess what this comment means since I haven't read the whole patch yet and have no idea what all these names refer to. Maybe it would be a good idea to clarify the expected usage of FirPlaceHolder?

120

Why do we need this? Wouldn't this be obvious from the type? (Maybe add it when it's actually used, then hopefully it will be obvious?)

137

Are these actually written in this patch? Or just read? Can we introduce them later?

flang/lib/Lower/Bridge.cpp
40

I'm seeing a lot of final overrides, is the whole class intended to be final by any chance? If so, we should just mark it as such upfront.

151

Might crash and burn if builder isn't instantiated yet.

189

Nit: Should we also assert that localSymbols is empty?

194

Nit: Changing the visibility doesn't seem to be related to the builder, so maybe move it up right after the creation of func? And then you can probably remove the changes to the insertion point from this patch and upstream them when they're actually relevant.

250

Nit: Is this actually used?

251

Where is this used? I see some references to it, but it doesn't seem to be populated (or I could be just missing it, it's Friday). Maybe we can upstream the SymMap in a future patch, to make this easier to review?

Yaay, it's great to see this patch! :)
I think it's a bit large though, maybe we can remove some things that aren't strictly necessary to make the test pass? That would make both this patch and future patches (where things are actually useed) easier to review.

It was discussed multiple time that the initial patch would be larger. We tried to trim it down and probably it could be a little bit smaller. As mentioned in the description, follow up patches will be smaller.

flang/lib/Lower/Bridge.cpp
251

SymMap was mostly present in the lowering directory. This patch moves it and makes some updates.

rovka added a comment.Jan 28 2022, 4:30 AM

Ok, I went over the dead code too and I don't see anything obviously wrong with it. I guess we can come back to it as more cases get supported in future patches.
LGTM with the nits addressed. You should probably wait for someone else to have a look too, since I'm not very familiar with lowering.

flang/lib/Lower/CallInterface.cpp
64
clementval marked 5 inline comments as done.

Address couple of typos and nits comments

clementval added inline comments.Jan 28 2022, 5:31 AM
flang/lib/Lower/CallInterface.cpp
64

Good catch

@clementval can you rebase or remove the parent so that the patch application will succeed?

@clementval can you rebase or remove the parent so that the patch application will succeed?

I removed the parent but looks like it's not enough. I'll rebase.

Thanks @clementval for the patch. The patch looks nice and well carved out.

I have the following suggestions. You can decide what from the following list to apply.

  1. I think the SymbolMap.h movement looks like an NFC and unrelated to this patch. Can you submit that directly without a review?
  2. I think from SymbolMap.cpp only lookupSymbol is used and other additions can be removed.
  3. I would recommend removing FirPlaceHolder from this patch since that deals with input and output of functions/subroutines and not related to an empty program. genFunctionType can be replaced with the following and - llvm::SmallVector<FirPlaceHolder> outputs;, llvm::SmallVector<FirPlaceHolder> inputs; removed.
template <typename T>
mlir::FunctionType Fortran::lower::CallInterface<T>::genFunctionType() {
 return mlir::FunctionType::get(&converter.getMLIRContext(), {}, {});
}

The declare function can be stripped of

for (const auto &placeHolder : llvm::enumerate(inputs))
        if (!placeHolder.value().attributes.empty())
          func.setArgAttrs(placeHolder.index(), placeHolder.value().attributes);
  1. I think bbc.cpp includes a lot of headers that are probably not needed at the moment like unparse-with-symbols.h, SCFToStandard.h,GreedyPatternRewriteDriver.h,TargetSelect.h. Similarly for the libraries as well.
This revision is now accepted and ready to land.Jan 28 2022, 8:30 AM
schweitz accepted this revision.Jan 28 2022, 8:51 AM
PeteSteinfeld accepted this revision.EditedJan 28 2022, 11:20 AM

I've built and tested both in-tree and out-of-tree builds, and all builds and tests without error.

After building, I tried running flang-new on a minimal program, and I got the following message:

error: code-generation is not available yet

@awarzynski , do we need to do something to enable running flang-new to create an executable now?

I've built and tested both in-tree and out-of-tree builds, and all builds and tests without error.

After building, I tried running flang-new on a minimal program, and I got the following message:

error: code-generation is not available yet

@awarzynski , do we need to do something to enable running flang-new to create an executable now?

The flang-new driver will need some parts to be upstream as well in order to be able to lower code. This is not part of this patch.

Remove some code

This revision was automatically updated to reflect the committed changes.

The flang-new driver will need some parts to be upstream as well in order to be able to lower code. This is not part of this patch.

Do you mean "lowering" code per-se, or driver code? I've only skimmed this patch through and it seems that I could start upstreaming the driver itself (i.e. being able to lower an empty program should be sufficient). I might be missing something though. @clementval ?

The flang-new driver will need some parts to be upstream as well in order to be able to lower code. This is not part of this patch.

Do you mean "lowering" code per-se, or driver code? I've only skimmed this patch through and it seems that I could start upstreaming the driver itself (i.e. being able to lower an empty program should be sufficient). I might be missing something though. @clementval ?

Just driver code I guess. I was just pointing that this patch does not enable lowering in the driver itself but just with bbc.

flang/lib/Lower/OpenACC.cpp