[flang2] Full support for opaque pointers

[xinliu-hnc]

This PR depends on PR #1321, rebase this branch after merging PR #1321 into the master branch.

This PR removes the redundant bitcast instructions generated by functions as well as the redundant bitcast instructions in some hard-coded strings, and for some hard-coded typed pointers in code blocks controlled by conditional compilation macros, we rewrite them. We also modify some test cases that use redundant bitcast instructions.

[bryanpkc]

@xinliu-hnc Please rebase the branch.

[xinliu-hnc]

@xinliu-hnc Please rebase the branch.

Rebased.

[bryanpkc]

LGTM.

[bryanpkc]

@xinliu-hnc Are any additional changes required? Have you tested the opaque pointer support on workloads outside of the Classic Flang regression tests?

[xinliu-hnc]

@xinliu-hnc Are any additional changes required? Have you tested the opaque pointer support on workloads outside of the Classic Flang regression tests?

I don't have any additional changes. I've tested NPB 3.4, SPEC CPU 2017 and SPEC OMP 2012, and there is no regression found.

[bryanpkc]

I compiled a simple test case:

function cdexp (in1)
  complex(kind=8) :: in1, cdexp
  cdexp = exp(in1)
end function cdexp

This emits the following IR:

define void @cdexp_(ptr %cdexp, ptr %in1) !dbg !15 {
L.entry:
    %.ka0000_338 = alloca <{double, double}>, align 16

    br label %L.LB1_336
L.LB1_336:
    %0 = bitcast ptr %.ka0000_338 to ptr, !dbg !18
    %1 = bitcast ptr %in1 to ptr, !dbg !18
    %2 = load <{double, double}>, ptr %1, align 1, !dbg !18
    %3 = extractvalue <{double, double}> %2, 0, !dbg !18
    %4 = bitcast ptr %in1 to ptr, !dbg !18
    %5 = load <{double, double}>, ptr %4, align 1, !dbg !18
    %6 = extractvalue <{double, double}> %5, 1, !dbg !18
    %7 = bitcast ptr @__mth_i_cdexp to ptr, !dbg !18
    %8 = call i32 (ptr, double, double, ...) %7 (ptr %0, double %3, double %6), !dbg !18
    %9 = load <{double, double}>, ptr %.ka0000_338, align 1, !dbg !18
    %10 = bitcast ptr %cdexp to ptr, !dbg !18
    store <{double, double}> %9, ptr %10, align 8, !dbg !18
    ret void, !dbg !19
}

As you can see, there is a lot of unnecessary bitcast instructions. Could you submit a follow-up PR to remove them?

[bryanpkc]

As you can see, there is a lot of unnecessary bitcast instructions. Could you submit a follow-up PR to remove them?

Apologies, this was a mistake on our part. The bitcast instructions are not seen after cherry-picking this PR correctly.

[bryanpkc]

I think we have sufficient approvals to merge this.

[inclyc]

Hi @bryanpkc @shivaramaarao,

Could you please double check why the alignment of load instructions in generated IR ? Let's see the example above:

%.ka0000_338 = alloca <{double, double}>, align 16

%.ka0000_338 is allocated on stack and has alignment = 16

%9 = load <{double, double}>, ptr %.ka0000_338, align 1, !dbg !18

Why this pointer is loaded with align 1 ? This will leads to bad code generation in backends I suppose? Would you mind give me some advice where is the alignment generated?

[pawosm-arm]

Hi @inclyc, could you type-in some minimal reproducer for the observed problem?

[inclyc]

Hi @inclyc, could you type-in some minimal reproducer for the observed problem?

Hi @pawosm-arm , thanks for your quick reply! Just see the example above: #1322 (comment)

[bryanpkc]

LLVM IR verifier will add align 1 even if the frontend omits the alignment. The problem is that flang2 fails to compute the correct type size for loads of complex types. I will submit a PR to fix the bug.

[bryanpkc]

#1449 should fix this.