[llvm-commits] [llvm] r78563 - in /llvm/trunk: include/llvm/CodeGen/ScheduleHazardRecognizer.h include/llvm/Target/TargetInstrItineraries.h lib/CodeGen/CMakeLists.txt lib/CodeGen/ExactHazardRecognizer.cpp lib/CodeGen/ExactHazardRecognizer.h lib/CodeGen/PostRASchedulerList.cpp lib/CodeGen/ScheduleDAGInstrs.cpp lib/CodeGen/SimpleHazardRecognizer.h
David Goodwin
david_goodwin at apple.com
Mon Aug 10 16:38:23 PDT 2009
Issuing two+ instructions in the same cycle that write the same
register is defined as producing an undefined result by all
architectures I am familiar with. For a super-scalar style issue, the
processor will just prevent these from dual issuing, issuing the first
in one cycle and the next in a later cycle. In a VLIW processor you
will likely get an undefined value. In either case we can correctly
model by leaving the Output dependence latency at 1.
BTW, I left the TODO there even though I don't understand it. Are
there really processor implementations that have a cost for reusing a
register?
David
On Aug 10, 2009, at 4:25 PM, Dan Gohman wrote:
> Hi David,
>
> This looks good. One question:
>
> On Aug 10, 2009, at 8:55 AM, David Goodwin wrote:
>>
>> + // Optionally add output and anti dependencies. For anti
>> + // dependencies we use a latency of 0 because for a multi-
>> issue
>> + // target we want to allow the defining instruction to issue
>> + // in the same cycle as the using instruction.
>> + // TODO: Using a latency of 1 here for output dependencies
>> assumes
>> + // there's no cost for reusing registers.
>> SDep::Kind Kind = MO.isUse() ? SDep::Anti : SDep::Output;
>> + unsigned AOLatency = (Kind == SDep::Anti) ? 0 : 1;
>
> I don't see how anti and output dependencies are different here. If
> two instructions with an anti-dependence can be issued in the same
> cycle, could not two instructions with an output-dependence also be
> issued in the same cycle?
>
> Dan
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list