Reduce IR generated by ACTIONs

[volsa]

Is your refactor request related to a problem? Please describe.
An action currently generates a getelementptr instruction for each member variable. For example the following ST code

PROGRAM main
    VAR
        foo : DINT;
        bar : DINT;
        baz : DINT;
    END_VAR
END_PROGRAM

ACTIONS
    ACTION AKT_foo
        foo := 1;
    END_ACTION
END_ACTIONS

will generate the following IR code

%main = type { i32, i32, i32 }

@main_instance = global %main zeroinitializer

define void @main(%main* %0) {
entry:
  %foo = getelementptr inbounds %main, %main* %0, i32 0, i32 0
  %bar = getelementptr inbounds %main, %main* %0, i32 0, i32 1
  %baz = getelementptr inbounds %main, %main* %0, i32 0, i32 2
  ret void
}

define void @main.AKT_foo(%main* %0) {
entry:
  %foo = getelementptr inbounds %main, %main* %0, i32 0, i32 0
  %bar = getelementptr inbounds %main, %main* %0, i32 0, i32 1
  %baz = getelementptr inbounds %main, %main* %0, i32 0, i32 2
  store i32 1, i32* %foo, align 4
  ret void
}

Describe the solution you'd like
Only foo is accessed, hence

define void @main.AKT_foo(%main* %0) {
entry:
  %foo = getelementptr inbounds %main, %main* %0, i32 0, i32 0
-  %bar = getelementptr inbounds %main, %main* %0, i32 0, i32 1
-  %baz = getelementptr inbounds %main, %main* %0, i32 0, i32 2
  store i32 1, i32* %foo, align 4
  ret void
}

Additional context
LLVM is already able to remove dead code (see output of opt -O1 -S input_file.ll) so this is only relevant for -Onone / -O0 therefore a "nice to have" and probably not too important.

[ghaith]

We could probably do this for all POUs. In theory we need to create a loading basic block where we could add the load instructions only when we encounter a variable we need to load (we could use a map for already loaded variables and load new ones on demand). Do you think this would increase llvm performance on large files?

[volsa]

Do you think this would increase llvm performance on large files?

Already discussed offline but just for completeness sake, no. LLVM doesn't seem to have any problems with regard to compile times whatsoever. However this is something that pops up very quickly when analyzing LLVM code as we generate a lot of dead-code. Seems like a good candidate for a "good first issue" though and otherwise just ignore for now?