Fwd: [RFC, PowerPC, Darwin] Clean up generation of ha16() / lo16() markers

[Don Crandall]

On 5/15/13 6:38 PM, David Fang wrote:
> Hal, Ulrich,
>
> Full llvm tests finished, and I did find 3 new failures:
>
> FAIL: LLVM :: DebugInfo/dwarf-public-names.ll (4448 of 9018)
> ******************** TEST 'LLVM :: DebugInfo/dwarf-public-names.ll' 
> FAILED *****
> ***************
> Script:
> -- 
> gtimeout 5m /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./llc 
> -generat
> e-dwarf-pubnames -filetype=obj -o 
> /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/
> test/DebugInfo/Output/dwarf-public-names.ll.tmp.o < 
> /Volumes/Isolde/sources/LLVM
> -svn/llvm.git/test/DebugInfo/dwarf-public-names.ll
> gtimeout 5m 
> /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./llvm-dwarfdu
> mp -debug-dump=pubnames 
> /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/test/Debug
> Info/Output/dwarf-public-names.ll.tmp.o | 
> /Users/fang/local/src/LLVM-svn/gcc40-c
> make-build/bin/./FileCheck 
> /Volumes/Isolde/sources/LLVM-svn/llvm.git/test/DebugI
> nfo/dwarf-public-names.ll
> -- 
> Exit Code: 1
> Command Output (stderr):
> -- 
> LLVM ERROR: expected relocatable expression
> ******************** TEST 'LLVM :: DebugInfo/namespace.ll' FAILED 
> **************
> ******
> Script:
> -- 
> gtimeout 5m /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./llc 
> -O0 -fil
> etype=obj < 
> /Volumes/Isolde/sources/LLVM-svn/llvm.git/test/DebugInfo/namespace.l
> l > 
> /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/test/DebugInfo/Output/namespac
> e.ll.tmp
> gtimeout 5m 
> /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./llvm-dwarfdu
> mp 
> /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/test/DebugInfo/Output/namespace
> .ll.tmp | 
> /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./FileCheck /Volu
> mes/Isolde/sources/LLVM-svn/llvm.git/test/DebugInfo/namespace.ll
> -- 
> Exit Code: 1
> Command Output (stderr):
> -- 
> LLVM ERROR: expected relocatable expression
> -- 
>
> ********************
> FAIL: LLVM :: DebugInfo/two-cus-from-same-file.ll (4462 of 9018)
> ******************** TEST 'LLVM :: 
> DebugInfo/two-cus-from-same-file.ll' FAILED *
> *******************
> Script:
> -- 
> gtimeout 5m /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./llc 
> /Volumes
> /Isolde/sources/LLVM-svn/llvm.git/test/DebugInfo/two-cus-from-same-file.ll 
> -o /V
> olumes/Isolde/builds/LLVM/gcc40-cmake-build/test/DebugInfo/Output/two-cus-from-s 
>
> ame-file.ll.tmp -filetype=obj -O0
> gtimeout 5m 
> /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./llvm-dwarfdu
> mp -debug-dump=info 
> /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/test/DebugInfo
> /Output/two-cus-from-same-file.ll.tmp | 
> /Users/fang/local/src/LLVM-svn/gcc40-cma
> ke-build/bin/./FileCheck 
> /Volumes/Isolde/sources/LLVM-svn/llvm.git/test/DebugInf
> o/two-cus-from-same-file.ll
> -- 
> Exit Code: 1
> Command Output (stderr):
> -- 
> LLVM ERROR: expected relocatable expression
> -- 
>
> ********************
>
> My branch is currently sync'd to r181825.
> Is there something newer on trunk that might address this?
> If so, what's the minumum revision I should re-merge from?
>
> Fang
>
>
>> Results sooner than expected:
>> Applying Ulrich's patches against the powerpc-darwin8 branch, the 
>> CodeGen/PowerPC tests (375) came clean, as did MC/PowerPC.
>>
>> % bin/llvm-lit -s -v test/CodeGen/PowerPC
>> Testing Time: 156.69s
>>   Expected Passes    : 372
>>   Expected Failures  : 3
>>
>> % bin/llvm-lit -s -v test/MC/PowerPC
>> Testing Time: 3.86s
>>   Expected Passes    : 11
>>
>> Is that good enough, or do you want a full test run?  (I'll start one 
>> now.)
>>
>> Fang
>>
>>>  Can you please test this on your Darwin system?
>>>
>>>  Thanks again,
>>>  Hal
>>>
>>>  ----- Forwarded Message -----
>>>  From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
>>>  To: llvm-commits at cs.uiuc.edu
>>>  Cc: "Hal Finkel" <hfinkel at anl.gov>
>>>  Sent: Wednesday, May 15, 2013 11:01:58 AM
>>>  Subject: [RFC, PowerPC, Darwin] Clean up generation of ha16() / lo16()
>>>  markers
>>>
>>>
>>>  Hello,
>>>
>>>  when targeting the Darwin assembler, we need to generate markers 
>>> ha16()
>>>  and
>>>  lo16() to designate the high and low parts of a (symbolic) immediate.
>>>  This
>>>  is necessary not just for plain symbols, but also for certain symbolic
>>>  expression, typically along the lines of ha16(A - B).  The latter 
>>> doesn't
>>>  work when simply using VariantKind flags on the symbol reference.
>>>
>>>  This is why the current back-end used hacks (explicitly called out 
>>> as such
>>>  via multiple FIXMEs) in the symbolLo/symbolHi print methods. I'd 
>>> like to
>>>  get rid of this special treatment as a first step towards getting 
>>> rid of
>>>  symbolLo/symbolHi itself.  This is interesting because it will allow
>>>  non-standard (but legal) use of the @l and @hi markers, e.g. to do
>>>  "lis ..., symbol at l"  (which is valid if unusual assembler, but will 
>>> not be
>>>  handled correctly by the llvm assembler right now).
>>>
>>>  The attached patch uses target-defined MCExpr codes to represent the
>>>  Darwin
>>>  ha16/lo16 constructs, following along the lines of the equivalent 
>>> solution
>>>  used by the ARM back end to handle their :upper16: / :lower16: 
>>> markers.
>>>  This allows us to get rid of special handling both in the
>>>  symbolLo/symbolHi
>>>  print method and in the common code MCExpr::print routine. Instead, 
>>> the
>>>  ha16 / lo16 markers are printed simply in a custom print routine 
>>> for the
>>>  target MCExpr types.
>>>
>>>  I don't have a live Darwin system to test on, but the Darwin assembler
>>>  tests in the test suite all still pass.
>>>
>>>  Does this look reasonable?
>>>
>>>  Bye,
>>>  Ulrich
>>>
>>>  (See attached file: diff-reloc-mcexpr)
>>
>>
>
Good evening,

On Darwin9 I get the same failures without adding Ulrich's patch. I 
build trunk with gcc 4.8 or 4.7.

Ulrichs' patch will be added to my G5 tree and rebuilt as soon as I 
finish the current unittesting with svn r181914, currently at ~57% on 
the G5/Darwin machine.

The patch has also been applied to a trunk build on a PPC linux (Ubuntu) 
build I began within the last hour. It is currently @ ~20%. Last test 
results showed the exact failures indicated by David. Will have more (or 
detailed) information for you later this evening.

Best regards
Don