Many thanks for your prompt reply. I mean, imagine you have 3 bits for condition flags in your instruction (e.g. overflow, zero, carry set, ...) for conditional executions AND there is no direct access to the Status Register, is it even possible to implement such scenario? On Fri, Jul 10, 2015 at 4:54 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 7/10/2015 9:32 AM, Sky Flyer wrote: > >> >> I wan to ask, what is exactly the purpose of TSFlags and can it be used >> for the condition handling in instructions? >> How can I implement the conditions in the instruction when I don't have >> access to the Status Register? >> > > These are target-specific flags that are then stored in the instruction > descriptor. You can use them to encode various properties of the > instruction that are of interest to your target. > > I'm not sure what you mean about condition handling, but TSFlags are > "static" in the sense that for a given opcode they remain fixed throughout > compilation. For conditional instructions you can have a flag there that > says that the instruction is conditional, but any variable characteristics > must be encoded in other ways. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150710/3373bb63/attachment.html>
On 7/10/2015 10:23 AM, Sky Flyer wrote:> Many thanks for your prompt reply. > > I mean, imagine you have 3 bits for condition flags in your instruction > (e.g. overflow, zero, carry set, ...) for conditional executions AND > there is no direct access to the Status Register, is it even possible to > implement such scenario? >There doesn't have to be any explicit status register. You can either create separate instructions for each condition, or have the condition as an extra operand. Let's take "add" for example. You could have several versions of add: add add unconditionally addc add if carry addz add if zero addo add if overflow and similarly for more complex conditions that your target could support, such as "carry or zero". This has the disadvantage that the instruction set can get really large, but if the number of conditional instructions is small or if the possible conditions vary from one operation to another, this may be a viable solution. The other option is to model the condition as an operand (I think ARM does that). So the add instruction could look like this: R0 = add R1, R2, C where C = 0: no conditions C = 1: zero C = 2: carry C = 4: overflow etc. This way the instruction set would remain small, but it may involve special handling for it to work with the integrated assembler (if the native instruction format is different than what you chose). You could use the TSFlags to indicate for each instruction which condition this instruction can modify. Taking the add again, it could modify all of the three: zero, carry and overflow, but a load could only modify zero (for example, specifics would depend on your target). -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Dear Krzysztof,
That was really much of help. I did go through the ARM code trying to
understand it.
One question that I have is, how "s" and "p" get
initialized? for example
in this code that I copied from ARMInstrFormats.td
// Same as I except it can optionally modify CPSR. Note it's modeled as an
input
// operand since by default it's a zero register. It will become an
implicit def
// once it's "flipped".
class sI<dag oops, dag iops, AddrMode am, int sz,
IndexMode im, Format f, InstrItinClass
itin,
string opc, string asm, string
cstr,
list<dag> pattern>
: InstARM<am, sz, im, f, GenericDomain, cstr, itin>
{
bits<4> p; // Predicate operand
bits<1> s; // condition-code set flag ('1' if the insn should
set the
flags)
let Inst{31-28} p;
let Inst{20} s;
let OutOperandList = oops;
let InOperandList = !con(iops, (ins pred:$p,
cc_out:$s));
let AsmString = !strconcat(opc, "${s}${p}",
asm);
let Pattern = pattern;
list<Predicate> Predicates [IsARM];
}
The same for TSFlags; when I want to used them for condition handling, how
do they get initialized?
On Fri, Jul 10, 2015 at 5:59 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 7/10/2015 10:23 AM, Sky Flyer wrote:
>
>> Many thanks for your prompt reply.
>>
>> I mean, imagine you have 3 bits for condition flags in your instruction
>> (e.g. overflow, zero, carry set, ...) for conditional executions AND
>> there is no direct access to the Status Register, is it even possible
to
>> implement such scenario?
>>
>>
> There doesn't have to be any explicit status register. You can either
> create separate instructions for each condition, or have the condition as
> an extra operand. Let's take "add" for example. You could
have several
> versions of add:
> add add unconditionally
> addc add if carry
> addz add if zero
> addo add if overflow
> and similarly for more complex conditions that your target could support,
> such as "carry or zero". This has the disadvantage that the
instruction
> set can get really large, but if the number of conditional instructions is
> small or if the possible conditions vary from one operation to another,
> this may be a viable solution.
> The other option is to model the condition as an operand (I think ARM does
> that). So the add instruction could look like this:
> R0 = add R1, R2, C
> where
> C = 0: no conditions
> C = 1: zero
> C = 2: carry
> C = 4: overflow
> etc.
>
> This way the instruction set would remain small, but it may involve
> special handling for it to work with the integrated assembler (if the
> native instruction format is different than what you chose).
>
> You could use the TSFlags to indicate for each instruction which condition
> this instruction can modify. Taking the add again, it could modify all of
> the three: zero, carry and overflow, but a load could only modify zero (for
> example, specifics would depend on your target).
>
>
>
> -Krzysztof
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150714/c8999f60/attachment.html>
Hi Krzystof, regarding your first solution (creating separate instruction), is it possible to somehow have cascading defm? for example, let's suppose aaa is a 3-bit condition a, and bb is a 2-bit condition b, all in one instruction, instead of having one multiclass with 2^5 conditions, is it possible to write 2^3 "a" conditions, and 2^2 "b" conditions, and the rest taken care by the TableGen? On Fri, Jul 10, 2015 at 5:59 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 7/10/2015 10:23 AM, Sky Flyer wrote: > >> Many thanks for your prompt reply. >> >> I mean, imagine you have 3 bits for condition flags in your instruction >> (e.g. overflow, zero, carry set, ...) for conditional executions AND >> there is no direct access to the Status Register, is it even possible to >> implement such scenario? >> >> > There doesn't have to be any explicit status register. You can either > create separate instructions for each condition, or have the condition as > an extra operand. Let's take "add" for example. You could have several > versions of add: > add add unconditionally > addc add if carry > addz add if zero > addo add if overflow > and similarly for more complex conditions that your target could support, > such as "carry or zero". This has the disadvantage that the instruction > set can get really large, but if the number of conditional instructions is > small or if the possible conditions vary from one operation to another, > this may be a viable solution. > The other option is to model the condition as an operand (I think ARM does > that). So the add instruction could look like this: > R0 = add R1, R2, C > where > C = 0: no conditions > C = 1: zero > C = 2: carry > C = 4: overflow > etc. > > This way the instruction set would remain small, but it may involve > special handling for it to work with the integrated assembler (if the > native instruction format is different than what you chose). > > You could use the TSFlags to indicate for each instruction which condition > this instruction can modify. Taking the add again, it could modify all of > the three: zero, carry and overflow, but a load could only modify zero (for > example, specifics would depend on your target). > > > > -Krzysztof > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/a3bc2012/attachment.html>