This code is copy from:
https://github.com/mchalupa/dg/blob/df6e4e23d2a0740ec9d9fa38e80032bd80556c95/CMakeLists.txt#L201-L214

void foo(int a) {
	int a; // remove this line
}

1. generate random test.c file [csmith]
2. compile test.c to binary [clang]
3. modify generated test.c file [fix-csmi.sh]
	- Here we replace csmith.h header with
	  necessery stuff to avoid header expansion
	  while compiling to llvm in next step
4. compile to LLVMIR test.ll [clang]
5. run llvm2c and generate decompiled.c [llvm2c]
6. modify decompiled.c file [decom-fix-csmi.sh]
	- Here we add csmith.h include and fix
	  types for functions from csmith.h
7. compile decompiled.c to binary [clang]
8. run compiled binaries and compare their outputs

If something goes wrong at any point then  all generated files
are copied to tmp (for debug purpose).

If we caught exception after running the compiled test.c then
we continue to the next step.

Parse basic types are:
- int
- char
- short
- long

- float
- double
- long double

and correctly recognize whether a type is signed or unsigned.

from metadataTypeInfo

E.g. `int *` or `unsigned int*`

Which prints strings to the llvm:errs().

From https://lists.llvm.org/pipermail/cfe-dev/2013-January/027302.html:
When a function has a struct parameter or return type,
Clang may lower a struct parameter into...
	- a "byval" pointer (for a struct with several different members)
	- a vector (for a struct with a few float members)
	- two doubles (for a struct with two double members)
	- an i64 (for a struct with two i32 members)
... and possibly more variations.

But there is no information in the metadata about types created in this way.
Therefore, we detect the use of the struct type as an argument or return value
of a function and do not reconstruct these types from the metadata.

Enable all (loop) passes from https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/IPO/PassManagerBuilder.cpp#L353-#L375:
```c
  if (EnableSimpleLoopUnswitch) {
    // The simple loop unswitch pass relies on separate cleanup passes. Schedule
    // them first so when we re-process a loop they run before other loop
    // passes.
    MPM.add(createLoopInstSimplifyPass());
    MPM.add(createLoopSimplifyCFGPass());
  }
  // Rotate Loop - disable header duplication at -Oz
  MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1));
  MPM.add(createLICMPass(LicmMssaOptCap, LicmMssaNoAccForPromotionCap));
  if (EnableSimpleLoopUnswitch)
    MPM.add(createSimpleLoopUnswitchLegacyPass());
  else
    MPM.add(createLoopUnswitchPass(SizeLevel || OptLevel < 3, DivergentTarget));
  // FIXME: We break the loop pass pipeline here in order to do full
  // simplify-cfg. Eventually loop-simplifycfg should be enhanced to replace the
  // need for this.
  MPM.add(createCFGSimplificationPass());
  addInstructionCombiningPass(MPM);
  // We resume loop passes creating a second loop pipeline here.
  MPM.add(createIndVarSimplifyPass());        // Canonicalize indvars
  MPM.add(createLoopIdiomPass());             // Recognize idioms like memset.
```
Test:
```bash
clang -S -emit-llvm -Xclang -disable-O0-optnone simple-for-loop-second-latch.c -o simple-for-loop-second-latch-noopt.ll
optpassPasses simple-for-loop-second-latch-noopt --loop-simplify --simplifycfg --loop-rotate --lcssa --licm --loop-unswitch --simplifycfg --instcombine --indvars
old_llvm2c simple-for-loop-second-latch-noopt-opt == new_llvm2c simple-for-loop-second-latch-noopt
```

1. map LOOP with BRANCH instruction (condition)
2. transform BRANCH inst. to if's or doWhile constructs

First:
```c
goto head;
head:
...
do
    goto head;
while( C );
```

transfrom into
```c
do
    head
while( C );

Second:
Cache result from loopInfoAnalysis in particular function

…h is greater than 1

This is hotfix. Following simple program cause the problem:

int length = 10;
int array[length];

llvm2c was unable to parse/find the length number
from alloca instruction operands.

function declaration

before this change, latchExpr was able to
print only single expression correctly

loopHeader is not always in the loop_latch->getTerminator()->getOperand(1)

from metadata

This commit should be 'fixup'ed with a commit removing these functions...

/usr/include/c++/12/bits/stl_iterator.h:1139:20: runtime error: applying
non-zero offset 18446744073709551608 to null pointer

since llvm2c produces non-compilable code with it:
input.c:
```c
int main(){
    int a[5] = {0,1,2,3,4};
    return a[0];
}
```
output.c:
```c
// function declarations
int main(void);

// global variable definitions
unsigned int __const_main_a[5] = {0,1,2,3,4,};

int main(void){
    int a[5];
    block0:
    a = __const_main_a;
    return a[0];
}
```
"error: array type 'int[5]' is not assignable"

input.c
```c
struct S3 {
  int arr[18];
};

struct S3 func_1() {
  struct S3 l_5;
  return l_5;
}
int main() { func_1(); }
```

input.ll
```llvmir
...
define dso_local void @func_1(%struct.S3* noalias sret(%struct.S3) align 4 %0) #0 !dbg !8 {
  call void @llvm.dbg.declare(metadata %struct.S3* %0, metadata !45, metadata !DIExpression()), !dbg !46
  ret void, !dbg !47
}
...
```
The problem was that the '%struct.S3*' type changed
from pointer to struct type. This change happens due
to misleading information from metadata which
corresponds to the type from the input.c file.

* https://github.com/marxin/cvise

e.g. `void foo();`

e.g.
struct s {
	struct s *ptr_to_s;
}

because in current situation there is no better way to handle this.

when e.g.
```c
typedef struct node {
  struct node *n
} * List;
List main_a;
```

we are consistent and for now decompile
a enum as a global variable

e.g. `int array[g_var];`
generates:
```llvmir
!18 = !DILocalVariable(name: "__vla_expr0", scope: !12, type: !19, flags: DIFlagArtificial)
!19 = !DIBasicType(name: "unsigned long", size: 64, encoding: DW_ATE_unsigned)
!20 = !DILocation(line: 0, scope: !12)
!21 = !DILocalVariable(name: "array", scope: !12, file: !3, line: 2, type: !22)
!22 = !DICompositeType(tag: DW_TAG_array_type, baseType: !5, elements: !23)
!23 = !{!24}
```
We can savely set an array size to 0, because type_kinds will differ, and
the deduced type will not be used. I hope this is a valid argument.
By valid I mean safe.

In llvm2c arrayType does not have a constructor for non-intergral type.
So we cannot set the variable name as a size argument...

So in the code:
```c
int a[2][3];

int main() {
	int b[2][3];
}
```
The type of array b wont be created again!

thanks @lzaoral for discussion

in llvm2c usually all struct have name prefixed with "s_"

and prepare for anonymous structs/unions

Thanks @lzaoral for help!

different names

e.g., type function occurs as arg type or return type

I wrongly assume that llvm always generates positive loop conditions, e.g. if this is true, then iterate, but after -O3 optimisations, loop condition might be negated: if this is false, then continue to the next iteration.

This new function will reverse the loop condition if the situation described above occurs!
This might need a proper solution - this is hackery, because we do not
replace the whole expression, just a printed character e.g. "<" -> ">=".

x = phi i32 [0, %beforeLoop]  [%y, %fromLoop] ; coming from %fromLoop means we
are in a next iteration

before this commit:
x = 0;
do {
        x = y;
        loopBody(y, ...);
} while ( cond )

after this commit:
x = 0;
do {
        loopBody(y, ...);
        x = y;
} while ( cond )

…eturn the m{ax,in}imum of the two operands.

My idea comes from https://reviews.llvm.org/D9293?id=&download=true

The expression:

    call i8 @llvm.umin.i8(i8 %a, i8 %b)

is equivalent to

    %1 = icmp ult i8 %a, %b
    %2 = select i1 %1, i8 %a, i8 %b

This is what llvm2c outputs:

    a < b ? a : b

…om the preheader block

This commit is probably the correct fix for what
fd4978d was trying to address.