[RFC] Enhancing location information

Subprojects Flang
1

Currently, flang only propagates basic location information when lowering from the parse-tree to MLIR. The frontend tracks all the inclusion and this information can be propagated to the location information attached on operation created during lowering.

In order to represents all the locations, the lowering would switch from a simple FileLineColLoc to a FusedLoc with an Integer attribute. The integer attribute encodes the position of the first inclusion location.

location1.inc

print*,'from location.inc'

location0.inc

include 'location1.inc'

test.f90

program test
include 'location0.inc'

end

The location information we would get from the print statement would include all the three files and line numbers from inclusion. The first location is the one that we have currently.

loc(fused<1 : i32>["location1.inc":1:8, "location0.inc":1:1, "location.f90":4:1])

Here is a draft PR that implement this RFC: [flang] Enhance location information by clementval · Pull Request #95862 · llvm/llvm-project · GitHub

Should we have this by default or would you prefer to have this enhanced location being generated only under a specific lowering option?

1 Like
2

I would tend to have it on by default. It makes sense to keep the full source location info in the IR. The only downside I see is the small extra compiler memory footprint (more location info created inside the contexts), but unless the include chains are crazy, I doubt this is a big deal.

Do you know how mlir reports operation errors for operation with such fused loc?

@abidh, what about debug info, do you need info about the includes? Would using FusedLoc in lowering break the way debug info are later generated (since you are already using FusedLoc for some purpose, although that can probably be combined)?

3

I saw an immediate problem and added a comment in PR 95862. We have previously discussed using FusedLoc to provide the information about the location of the members of derived type to the debug info generator. I was wondering if that will be difficult with FusedLoc being also used for include location.

4

I think we can still accommodate both in a FusedLoc. What we will need is to use a custom attribute that will describe what is embedded in the FusedLoc so we can distinguish between main location, derived type members and inclusions. I used the IntegerAttr to specify the index of the first inclusion location just because it is already available and seemed straight forward.

5

I did a small test and the first location is used to emit the error. So we would have the save behavior than now regarding MLIR error reporting.

location1.inc:1:8: error: 'cuf.allocate' op pinned and stream cannot appears at the same time