This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Change custom syntax of emitc.include op to resemble C
ClosedPublic

Authored by simon-camp on Jul 1 2021, 7:03 AM.

Details

Summary

This changes the custom syntax of the emitc.include operation for standard includes.

Diff Detail

Event Timeline

simon-camp created this revision.Jul 1 2021, 7:03 AM
simon-camp requested review of this revision.Jul 1 2021, 7:03 AM
marbre added a comment.Jul 1 2021, 7:18 AM

LGTM and I can commit on your behalf. However, as Mehdi suggested this change, I would like to wait for his feedback first.

mlir/lib/Dialect/EmitC/IR/EmitC.cpp
120

nit: No trailing dot.

Looks nicer :-)

mlir/include/mlir/Dialect/EmitC/IR/EmitC.td
143

Unrelated to this change but isn't system_include more common terminology for this?

mlir/lib/Dialect/EmitC/IR/EmitC.cpp
138

Is verification needed here to ensure include was parsed?

marbre added inline comments.Jul 1 2021, 8:20 AM
mlir/include/mlir/Dialect/EmitC/IR/EmitC.td
143

Good question! I struggled when initially choosing a name for the attribute. Following cppreference here, it seemed to me that standard_include might be more appropriate as they always talk about "standard include directories" but never about system includes.

Nice!

mlir/test/Dialect/EmitC/ops.mlir
3

This isn't quite usual, what are you trying to catch here?

What is more common is to reparse the custom print instead to check that printer and parser are matching each other.

marbre added inline comments.Jul 1 2021, 1:11 PM
mlir/test/Dialect/EmitC/ops.mlir
3
mehdi_amini added inline comments.Jul 1 2021, 1:19 PM
mlir/test/Dialect/EmitC/ops.mlir
3

I don't quite get the motivation actually, River is OOO for a couple of weeks, I can check with him when he'll popup online.

In the meantime (unless you can explain why) I rather leave this out.

mehdi_amini added inline comments.Jul 1 2021, 1:25 PM
mlir/test/Dialect/EmitC/ops.mlir
3

Got confirmation from River:

There were a few cases long ago where they tested for specific bugs. I don't think those make sense anymore though, and are just being cargoculted forward via copy/paste.

marbre added inline comments.Jul 1 2021, 1:33 PM
mlir/test/Dialect/EmitC/ops.mlir
3

Sry, I try to clarify. With the first mlir-opt we check if the custom form can be parsed. By adding the -mlir-print-op-generic, these

emitc.include <"test.h">
emitc.include "test.h"

get printed as

"emitc.include"() {include = "test.h", is_standard_include} : () -> ()
"emitc.include"() {include = "test.h"} : () -> ()

which than get parsed afterwards. Thus both formats get parsed. This is how I understand the motivation in the PDL test and thus we adopted this. But leaving this out is fine as well. As proposed we can parse the custom format with the second mlir-opt call by removing -mlir-print-op-generic from the first call.

mehdi_amini added inline comments.Jul 1 2021, 1:43 PM
mlir/test/Dialect/EmitC/ops.mlir
3

Thus both formats get parsed.

Yes, but what is the point? What are we testing with reparsing the generic format?

marbre added inline comments.Jul 1 2021, 1:48 PM
mlir/test/Dialect/EmitC/ops.mlir
3

Thus both formats get parsed.

Yes, but what is the point? What are we testing with reparsing the generic format?

Indeed. As discussed on Discord we will change to mlir-opt | mlir-opt.

Address review comments.

simon-camp marked 9 inline comments as done.Jul 2 2021, 12:32 AM
simon-camp added inline comments.
mlir/lib/Dialect/EmitC/IR/EmitC.cpp
138

With the latest revision a more explicit error message is generated.

marbre accepted this revision.Jul 5 2021, 7:38 AM
This revision is now accepted and ready to land.Jul 5 2021, 7:38 AM
This revision was automatically updated to reflect the committed changes.