This is an archive of the discontinued LLVM Phabricator instance.

[Flang] Add a factory class for creating Complex Ops
ClosedPublic

Authored by kiranchandramohan on Nov 17 2021, 3:38 PM.

Details

Summary

Use the factory class in the FIRBuilder.
Add unit tests for the factory class function and the convert function
of the Complex class.

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

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald Transcript
kiranchandramohan requested review of this revision.Nov 17 2021, 3:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 17 2021, 3:38 PM
kiranchandramohan edited the summary of this revision. (Show Details)Nov 17 2021, 3:41 PM
This revision is now accepted and ready to land.Nov 18 2021, 12:28 AM
rovka accepted this revision.Nov 18 2021, 1:28 AM

LGTM with nits.

flang/include/flang/Optimizer/Builder/Complex.h
33

Nit: Can these methods be const?

44

Nit: Why not pass the Part directly, instead of a bool?

flang/lib/Optimizer/Builder/Complex.cpp
28
flang/unittests/Optimizer/Builder/ComplexTest.cpp
89

Can you add another test case to check the values that are inserted and extracted? (I.e. not just the types).

awarzynski added inline comments.Nov 18 2021, 1:37 AM
flang/include/flang/Optimizer/Builder/FIRBuilder.h
60–63

[nit] Could you add examples?

kiranchandramohan marked 3 inline comments as done.

Address review comments.
Mark two functions as const, simplify a function by calling another,
provide an example.

kiranchandramohan marked 2 inline comments as done.Nov 18 2021, 3:20 AM
kiranchandramohan added inline comments.
flang/include/flang/Optimizer/Builder/Complex.h
44

I think this is a convenience function for external users. i.e they don't have to know about Part.

flang/unittests/Optimizer/Builder/ComplexTest.cpp
89

I think since there are insertsOps and ExtractOps, it will be difficult to do that in the unittest. If I am missing a point, please let me know.

IR testing will come along with lowering later.

rovka added inline comments.Nov 18 2021, 4:38 AM
flang/include/flang/Optimizer/Builder/Complex.h
33

I meant the methods themselves, not the return type, i.e.
mlir::Type getComplexPartType(...) const;

44

I guess this is a matter of taste, but using Part instead of bool would make calls inherently clear, without people having to spell out /* isImagPart=*/ before the argument. Plus, Part is already public.

That's just my 2c, feel free to leave it as is.

flang/unittests/Optimizer/Builder/ComplexTest.cpp
89

Fair enough.

kiranchandramohan marked 2 inline comments as done.

mark functions as const

flang/include/flang/Optimizer/Builder/Complex.h
33

my bad. Corrected.

44

I am leaving it as is. I don't have a strong opinion. It kind of matches the way some information is there in the Semantics phase. See example below.

template <int KIND>
CC genarr(const Fortran::evaluate::ComplexComponent<KIND> &x) {
  auto loc = getLoc();
  auto lambda = genarr(x.left());
  auto isImagPart = x.isImaginaryPart;
  return [=](IterSpace iters) -> ExtValue {
    auto lhs = fir::getBase(lambda(iters));
    return fir::factory::Complex{builder, loc}.extractComplexPart(lhs,
                                                                  isImagPart);
  };  
}