This is an archive of the discontinued LLVM Phabricator instance.

[fir] Add fir.embox conversion
ClosedPublic

Authored by clementval on Nov 12 2021, 4:11 AM.

Details

Summary

Convert a fir.embox operation to LLVM IR dialect.
A fir.embox is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.

Current limitiation: alignment is set by default but should be retrieved in the specific target.

This patch is part of the upstreaming effort from fir-dev branch.

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

Diff Detail

Event Timeline

clementval created this revision.Nov 12 2021, 4:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2021, 4:11 AM
Herald added a subscriber: mehdi_amini. · View Herald Transcript
clementval requested review of this revision.Nov 12 2021, 4:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2021, 4:11 AM
clementval edited the summary of this revision. (Show Details)Nov 12 2021, 4:12 AM

I've only managed to skim through - will revisit next wekk.

  1. I think that the overall readability of CodeGen.cpp could be improved if EmboxCommonConversion was separate from the other conversions (which tend to me compact and self-contained). Perhaps a dedicated file?
  2. F18ADDENDUM - it would be great to avoid F18 (here and in other places). Perhaps FLANG_ADDENDUM?
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1217–1221

Why not inline this?

1331
  1. Why?
  2. Could you "inject" this comment into the assert?
flang/test/Fir/convert-to-llvm.fir
1218

Where is 9 coming from? I couldn't find it.

1219

I've only managed to skim through - will revisit next wekk.

  1. I think that the overall readability of CodeGen.cpp could be improved if EmboxCommonConversion was separate from the other conversions (which tend to me compact and self-contained). Perhaps a dedicated file?

I would prefer to do this kind of file/code restructuring after the upstreaming is done. EmboxCommonConversion is (will be) used by other conversion pattern here. We already have such common struct for ValueOpCommon.

rovka added inline comments.Nov 15 2021, 2:32 AM
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1070

Do we really need op, or could we just replace all of this with

auto func = thisBlock->getParentOfType<mlir::LLVM::LLVMFuncOp>()

?

1096

Minor nit: I think comparing with nullptr is clearer than casting to bool (but I'm not sure what's idiomatic for FIR types).

1171

Is it possible to have more than 1 len param? I think this could use a comment on why we only care about the last one.

1230

This looks like it could easily get out of sync with lowering. Would it be difficult to move this logic somewhere common?

1247
flang/test/Fir/convert-to-llvm.fir
1218
1238
1239
1265

I think we should have some tests in this style for various [elem_size, type_code] combinations, and especially char if possible.

flang/lib/Optimizer/CodeGen/CodeGen.cpp
1070

I think such a function does not exist.

clementval marked 14 inline comments as done.Nov 15 2021, 4:12 AM
clementval added inline comments.
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1070

@kiranchandramohan is right. Block does not have such function.

1331

If I'm not wrong embox with shape are first lowered to xembox op and then converted to LLVM IR.

  1. done
flang/test/Fir/convert-to-llvm.fir
1218

That's correct.

1219

Thanks for catching this.

clementval marked 3 inline comments as done.

Address comments

  1. F18ADDENDUM - it would be great to avoid F18 (here and in other places). Perhaps FLANG_ADDENDUM?

The descriptor field is named f18Addendum. I think it's easier to follow if the name correspond to the name in code.

awarzynski added inline comments.Nov 15 2021, 5:55 AM
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1053

DOXYGENME?

[nit] IIUC, lowering is used in Flang to refer to lowering from parse tree to FIR. This part is usually referred to as "code-gen". And this file deals with "conversions" specifically. Perhaps "lowering" --> "converting"? For the sake of consistency.

1063–1064
1066–1067

This isn't correct, is it?

1072

Why 1?

1078–1085

I think that this can be static, no?

1264

Perhaps a daft question, but what's the difference between "descriptor" and "descriptor prefix" here?

1293

genConstantOffset takes an int rather than bool.

Also, hasAddendum is not an offset, is it?. Similarly above (getCFIAttr does not generate an offset, does it). In general, based on the usage in this method, it seems that genConstantOffset should be renamed as genConstant.

flang/test/Fir/convert-to-llvm.fir
1206

Could add a note explaining the origins of the indices within the descriptor?

1229
1230
1253

Could you explain "why" 1? (i.e. that's the value of CFI_attribute_pointer, right?).

1268

Why 2?

1276
1329

Why 1?

clementval marked 13 inline comments as done.

Address comments

flang/lib/Optimizer/CodeGen/CodeGen.cpp
1053

We use Lower on at least 13 patterns in this file. Anyway I switched to conversion here. Not sure what do you want to "doxygen" here.

1066–1067

Why?

1072

Array size of 1

1264

Again, not the original author so just guessing. This is generating the first part of the descriptor (prefix) but not the last part with the dimensions and so on.

1293

I split this. genConstantOffset is used mainly for GEP op creation and get the offset type from the TypeConverter. For constant created for values, we will use a separate function that just creates integer constants.

flang/test/Fir/convert-to-llvm.fir
1229

Thanks!

1230

Thanks!

awarzynski added inline comments.Nov 15 2021, 8:04 AM
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1066–1067
 auto func = mlir::isa<mlir::LLVM::LLVMFuncOp>(op)
			                    ? mlir::cast<mlir::LLVM::LLVMFuncOp>(op)
			                    : op->getParentOfType<mlir::LLVM::LLVMFuncOp>();

To me this means:

  • If this is a LLVMFuncOp, use it as the block for the newly inserted alloca.
  • Otherwise, use the block corresponding to the parent LLVMFuncOp

The comment above this statement suggests otherwise. Or is it just me?

clementval added inline comments.Nov 15 2021, 8:14 AM
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1066–1067

This is what the comment says.

auto op = rewriter.getInsertionBlock()->getParentOp(); might be placed under the comment so it's easier to understand. If you have a better way to describe this feel free to propose it.

awarzynski added inline comments.Nov 15 2021, 9:00 AM
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1063–1069

OK, my bad, the comment refers to auto op = rewriter.getInsertionBlock()->getParentOp(); as well. I was only looking at the comment and the code that follows.

I think that op is a misleading name (I've just assumed that it's the operation currently being converted). I suggest updating to something more descriptive.

As for the comment itself - IMHO the bit that confused me (2nd and 3rd line) simply repeats what the code does and does not add much. I would delete it. The first sentence in the comment ("// Order to find the Op in whose entry block the alloca should be inserted.") can also be deleted if you rename func as something more descriptive, e.g. funcForInsertion or funcToInsertAllocaInto.

flang/lib/Optimizer/CodeGen/CodeGen.cpp
1063–1069

Since this has become controversial, I think we can take this opportunity to convert this code into a function that returns the correct LLVM FUncOp for the alloca to be inserted.

getLLVMFuncToInsertAlloca

Something similar was suggested by @jeanPerier in the original PR.
https://github.com/flang-compiler/f18-llvm-project/pull/1066#pullrequestreview-760987822

clementval marked 2 inline comments as done.

Move code to find alloca insert func

flang/lib/Optimizer/CodeGen/CodeGen.cpp
1063–1069

I think @kiranchandramohan is right. This is better in a separate function and should be easier to understand. I just updated the patch with this change.

Make sense, thanks for all the updates! It seems that genConstantOffset is still used to generate a lot of values that are not "offsets". Are you going to rename it? Otherwise, just a few minor things.

flang/include/flang/Optimizer/Support/TypeCode.h
29

[nit] I think that width would be more accurate (bits could mean the actual data too)

flang/lib/Optimizer/CodeGen/CodeGen.cpp
1070
  1. size is hard-coded to 1. Can you update the comment accordingly?
  2. Could you document what the return value is?
1077

I thought that you would introduce another method to generate constant values? genConstantOffset is rather counter-intuitive here. genConstantVal would make more sense here.

1180–1194

[nit] Perhaps move above doInteger and other lambdas not needed for these 2 cases? Basically, this function is a bit dense and it's not obvious what the key cases are. Or add comments?

1235

What's this name of? Global descriptor, right?

1237

This checks for the global symbol in FIR?

1243

This checks for the global symbol in LLVM?

1276

[nit] I think that this value is first and foremost the constructed "descriptor". The fact that it's a "dest"ination when calling insertField is IMO just an implementation detail. Perhaps just add a comment that documents "what" this method produces? Otherwise, dest is a bit enigmatic.

1313–1314
clementval marked 11 inline comments as done.Nov 16 2021, 12:45 PM
clementval added inline comments.
flang/include/flang/Optimizer/Support/TypeCode.h
29

I changed it to bitwidth as it is reference in the top comment.

flang/lib/Optimizer/CodeGen/CodeGen.cpp
1077

I did genI32Constant.

1180–1194

This actually trigger couple of regression. Adding comments is fine.

1235

name (once lowered) of the global for the corresponding type descriptor.

1237

Yes it looks in the fir.global ops that have not been converted yet.

1243

Yeah we check in the llvm global since it might have been converted already.

clementval marked 6 inline comments as done.

Rebase + address comments

A few minor comments.

flang/lib/Optimizer/CodeGen/CodeGen.cpp
169

Nit: array|struct|vector

1356

Notify failure and testcase.

flang/test/Fir/convert-to-llvm.fir
1286

Is the logical type missing?

clementval marked 2 inline comments as done.

Address more comments

LGTM. Please wait for @awarzynski.

This revision is now accepted and ready to land.Nov 17 2021, 9:21 AM
clementval added inline comments.Nov 17 2021, 10:59 AM
flang/lib/Optimizer/CodeGen/CodeGen.cpp
1356

switch to notifyMatchFailure. Testcase cannot be added at this time because the TypeConverter will trigger a TODO before we can reach this point.

flang/test/Fir/convert-to-llvm.fir
1286

Not really missing. I didn't add test for every possible typecode. Added one for logical.

awarzynski accepted this revision.Nov 18 2021, 1:21 AM

LGTM, thanks for working on this!

This revision was automatically updated to reflect the committed changes.