chapel-lang/chapel — pull request #399 by mppf (2014-09-12 13:20:11+00:00)
Title: Bug fixes for LLVM back-end

Address a number of problems with the LLVM backend discovered
in more thorough testing.

All tests were printing out errors like
$CHPL_HOME/modules/standard/IO.chpl:759: warning: Could not find extern
def of S_IRWXU
I've disabled this warning for now (so we can have more sane testing),
but that's not the best long-term solution (see below).

These tests rely on C backend functionality and gained a skipif:
compflags/shannon/cpplines/cppLines
statements/diten/op_equals_using_C_primitive
execflags/sungeun/about

These tests were failing because of a bug in how the LLVM backend
handled calling functions compiled by clang that pass structures
in registers or return structures in registers. I've fixed those bugs
by reworking that section of code.
extern/bradc/structs/externFloat4calls
extern/bradc/structs/externFloat4calls.someFields
I also added a new test to stress these capabilities:
extern/ferguson/crazyRecord

This test was failing because the LLVM backend tried to pass a homogenous
tuple by value (instead of by pointer) to an extern function.
users/ferguson/tuple_to_extern
Because Chapel passes them by pointer and C always will (e.g. int arr[10] as
an argument will pass a single pointer, and not 10 values, as function
arguments), I've modified codegenValue to keep star tuples/homogenous tuples
as pointers with isLVPtr set. (I investigating making them have isLVPtr=value
but that messed up other logic to do with copying them...). Since
codegenValue never really produces the value anymore, I needed to modify
codegenCopy to always use memcpy for star tuples.

These tests used #defines when a static inline function would do. That's
a problem because the LLVM backend doesn't support complicated extern
#defines (see below remaining issues).
studies/filerator/findfiles
studies/filerator/walk
studies/filerator/globberator
studies/glob/test_glob
I changed the #defines to static inline functions.

Remaining Issues:
link/sungeun/static_dynamic does not work with --llvm
S_IRWXU and friends won't work unless we:
- manually add a wrapper
- support math directly when handling macros
- or, add some kind of macro-to-function feature.

Testing:
All tests pass with -compopts --llvm except for
[Error matching program output for io/fsouza/chown/permission_error]
[Error matching compiler output for link/sungeun/static_dynamic (compopts: 1)]
[Error matching compiler output for link/sungeun/static_dynamic (compopts: 2)]
[Error matching compiler output for link/sungeun/static_dynamic (compopts: 3)]
[Error matching program output for types/range/hilde/maximalRange (compopts: 1

I'm leaving static_dynamic as future work and the other two fail for me
in C backend testing.

I'll do GASNET+LLVM and --llvm-wide-opt testing next.