[llvm-commits] [llvm] r147825 - /llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp

[Chandler Carruth]

On Mon, Jan 9, 2012 at 6:44 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Jan 9, 2012, at 6:10 PM, Chandler Carruth wrote:
>
> On Mon, Jan 9, 2012 at 5:34 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
>> As always, test cases for this stuff are insane.
>>
>
> This is starting to worry me. How will we ever catch regressions? It seems
> like there has to be a way to write test cases for this kind of stuff, even
> if it means digging out and exposing more of the innards... Maybe this is a
> place where unit tests could actually work? I haven't looked at it at all,
> I'm just looking for a way to write non-insane test cases for this (clearly
> tricky) part of the backend....
>
>
> The particular issue is exposed when an instruction is at a function
> offset == 2 (mod 4), and it references an 8-byte aligned constant pool
> entry, and there is at least 4k of basic block both before and after the
> instruction.
>
> While it may be practical to write a unit test for that particular case,
> it seems like a dead end for most other cases. A codegen pass depends on a
> lot of data structures being in place, and generating MI IR
> programmatically is horrible.
>

Sorry, I didn't mean to call any particular attention to this patch or its
specifics...

As we discussed before, the best solution is to feed serialized MI IR
> directly into the pass. It's just a small matter of engineering.
>

I agree with the strategy, sorry that my previous email was a bit confusing.

I'm mostly just trying to periodically check to see if we've crossed the
threshold where the engineering for the serialization and deserialization
of MI IR needs to be done. It isn't clear to me where the threshold is, but
it seems we must be close to it given complexity in the ARM backend....

Anyways, it seems you're not worried yet, so I'll go away for a while
again. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120109/d6703717/attachment.html>