[LLVMdev] Random question about the x86 backend (and backends in general I suppose)

[Craig Topper]

I can't speak directly to the questions themselves, but I'll ask a couple
back. When you say that some instructions are missing mayLoad, do these
instructions have patterns? Tablegen can infer
mayLoad/mayStores/hasSideEffects from patterns so it doesn't always need to
be listed explicitly in the td files.

Instructions without patterns are marked hasSideEffects=1 which is more
restrictive than mayLoad/mayStore.


On Mon, Dec 30, 2013 at 1:56 PM, Chandler Carruth <chandlerc at google.com>wrote:

> Having worked with a few people to better understand the tablegen
> descriptions of instructions and patterns in LLVM's backend and looking at
> x86's pretty heavily, I have some questions:
>
> 1) Are there instruction definition flags that are really just "when
> needed"? I'm thinking of things like "mayLoad" which is really alarmingly
> missing from a bunch of instructions in x86 which load. Is this OK? Is this
> a bug, or just suboptimal?
>
> 2) Are all of the flags in Target.td (lines 356 - 381) the "recommended"
> set? Are any of them no longer really important to mark?
>
> 3) It would be really nice to keep track of the flags for instructions
> which are added (or removed) from the "recommend set", and whether or not
> backends have had their instruction definitions audited to be up-to-date
> here. Essentially, I wonder if it would be useful to keep PRs open with a
> nice list of low-hanging maintenance tasks on the instruction definition
> tables for people interested.
>
> 4) If I'm reading the td files and I see things that are obviously wrong
> (for example, an instruction which loads but is not marked as such, or
> instructions which should be marked as (potentially) trivially
> rematerializable), should I just fix them and submit those fixes? Can I
> even write test cases for most of these? Clearly, what I consider
> "obviously wrong" will be informed by answers to #1 and #2 above.
>



-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131230/b8fdfb54/attachment.html>