CN109240701A - 一种面向谓词执行高性能dsp的指令依赖关系分析方法 - Google Patents

Abstract

一种面向谓词执行高性能DSP的指令依赖关系分析方法，对于基本块内的某条指令，从指令I的前一条指令开始，逆序遍历基本块内的指令去尝试解除依赖分析需求，同时确认指令I与哪些指令有依赖关系；每遍历到一条指令X，进行如下处理：S1：分析指令I和指令X之间是否可能有依赖关系；S2：获得指令X的谓词域信息，并根据指令I和指令X的条件执行关系，决定是否结束对指令X的后续处理；S3：如果还没有结束对指令X的处理，针对指令I的依赖分析需求，结合指令X的条件执行特性开展相应的依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。本发明具有原理简单、操作简便、能够充分发挥硬件性能等优点。

Description

一种面向谓词执行高性能DSP的指令依赖关系分析方法

技术领域

本发明主要涉及到代码的编译优化方法，特指一种面向谓词执行高性能DSP的指令依赖关系分析方法。

背景技术

在编译过程中，要完成基本块内指令的调度，提高代码的并行度，必须要先对基本块内指令依赖关系进行全面有效的分析。正确有效的依赖关系是指令调度过程所需的关键信息。依赖关系分析指的是确定一个基本块内指令间的顺序关系，这种关系是代码正确执行所必须遵循的。

基本块内指令间的依赖关系一般是通过有向无环图(DAG)来描述的。该图描述了各指令与其他指令的执行顺序依赖关系。一条指令与其他指令之间的依赖关系决定了该指令必须在哪些指令执行完毕之后才能够执行。

现有技术中，在构造基本块的依赖DAG的过程中，确定某条指令所依赖的其他指令的基本方法如下：依次处理基本块的所有指令，对于每条指令Ia，分析它与它之前的每一条的指令Ib的冲突关系，如果两者之间冲突则在两指令之间添加一条边来表示它们之间的依赖关系。通过这种方法得到的依赖关系可以保证代码正确执行。但是，在谓词执行情况下，任意指令都可能是条件执行的，因此它也存在如下问题：

1)不能充分识别指令间的并行性。对于条件执行指令，它不能将谓词域的执行条件互补的两条指令的实际可并行执行关系分析出来。对于硬件资源可配置的嵌入式处理器，特别是VLIW体系结构的高性能DSP，它不能充分发现条件执行的硬件配置指令与其他指令的可并行执行关系。

2)会导致产生一些不必要的边。如果指令Ic依赖于Ib，Ib又依赖于Ia，那么它将认为Ic同时依赖于Ia和Ib，即使这种依赖仅仅是数据上的依赖。这些冗余的依赖关系会对相关的代码优化造成干扰。

正是由于上述问题，使得它不能得到指令与其之前的条件执行指令之间的准确依赖关系，最终得到的基本块依赖DAG不能较好地描述指令间的并行关系，进而将导致指令调度结果不能充分发挥硬件的性能。

发明内容

本发明要解决的技术问题就在于：针对现有技术存在的技术问题，本发明提供一种原理简单、操作简便、能够充分发挥硬件性能的面向谓词执行高性能DSP的指令依赖关系分析方法。

为解决上述技术问题，本发明采用以下技术方案：

一种面向谓词执行高性能DSP的指令依赖关系分析方法，对于基本块内的指令I，从指令I的前一条指令开始，逆序遍历基本块内的指令去尝试解除依赖分析需求，同时确认指令I与哪些指令有依赖关系，直到依赖分析需求都被解除或逆序到达基本块入口；每遍历到一条指令X，进行如下处理：

S1：不考虑指令I和指令X的谓词域，分析指令I和指令X之间是否有依赖关系；如果没有，结束对指令X的处理；否则进行下面步骤的处理；

S2：获得指令X的谓词域信息，并根据指令I和指令X的条件执行关系，决定是否结束对指令X的后续处理；

S3：如果还没有结束对指令X的处理，针对指令I的依赖分析需求，结合指令X的条件执行特性开展相应的依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。

作为本发明的进一步改进：将硬件资源配置、访问存储器、使用变量这三种导致DSP的指令间存在依赖关系的主要原因对应成指令进行依赖关系分析的处理需求，分别称为配置依赖分析需求、访存依赖分析需求、变量依赖分析需求。

作为本发明的进一步改进：在步骤S5中，是针对指令I的配置依赖分析需求、访存依赖分析需求、变量依赖分析需求，结合指令X的条件执行特性开展相应的配置依赖分析、访存依赖分析、变量依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。

作为本发明的进一步改进：在为基本块内的指令1分析依赖关系之前，先对指令I进行预处理，为后续分析过程确定初始信息。

作为本发明的进一步改进：所述预处理的过程包括：

a、根据指令I所使用的源变量和目标变量，创建依赖变量集合；

b、分析出指令I的谓词域的执行条件变量和条件模式；

c、假定指令I对应的三种依赖分析需求都未解除，将相应的标志位置为FALSE。

作为本发明的进一步改进：所述步骤S3为对指令I进行各种依赖分析需求，包括：

如果指令I的配置依赖分析需求尚未解除，则考虑谓词执行特性，分析指令I对指令X是否确实存在配置依赖，分析指令I的硬件配置依赖分析需求是否可以因指令X而解除；如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条配置依赖指令的执行条件互补，则可以解除。

作为本发明的进一步改进：所述步骤S3为对指令I进行各种依赖分析需求，包括：

如果指令I和指令X都是访存指令且指令I的访存依赖分析需求尚未解除，则考虑谓词执行特性，分析指令I对指令X是否确实存在访存依赖，分析I的访存依赖分析需求是否可以因指令X而解除；如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条访存依赖指令的执行条件互补，则可以解除。

作为本发明的进一步改进：所述步骤S3为对指令I进行各种依赖分析需求，包括：

如果指令I的所有变量依赖分析需求尚未全部解除，则考虑谓词执行特性，分析指令I对指令X是否确实因某些变量而存在依赖，分析指令I的这些变量对应的变量依赖分析需求是否可以因指令X而解除；如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条变量依赖指令的执行条件互补，则可以解除；在此基础上，进一步分析指令I的所有变量对应的变量依赖分析需求是否都已经解除；如果是，则指令I的变量依赖分析需求完整解除。

与现有技术相比，本发明的优点在于：

本发明使用的基本块内指令间依赖关系分析方法，在分析过程中综合考虑了硬件的谓词执行特性，能够在指令序列中包含条件执行和无条件执行两类指令的情况下，分析指令间的配置依赖关系、访存依赖关系、变量依赖关系。分析过程中特别考虑了互补条件执行指令对的情况，能为支持谓词执行的DSP或嵌入式处理器准确分析出指令所依赖的其他指令，并有效避免指令间因依赖关系传递形成的冗余依赖边。这能给基本块调度提供更多改善指令并行度的机会。

附图说明

图1是本发明在具体实施例中基本块内指令间依赖关系分析的顶层控制过程的操作状态转换图。

图2是本发明在具体实施例中基本块内的指令I与其前面的某条指令X的配置依赖关系分析的操作状态转换图。

图3是本发明在具体实施例中基本块内的指令I与其前面的某条指令X的访存依赖关系分析的操作状态转换图。

图4是本发明在具体实施例中基本块内的指令I与其前面的某条指令X的变量依赖关系分析的操作状态转换图。

具体实施方式

以下将结合说明书附图和具体实施例对本发明做进一步详细说明。

本发明的面向谓词执行高性能DSP的指令依赖关系分析方法，对于基本块内的指令I，从指令I的前一条指令开始，逆序遍历基本块内的指令去尝试解除依赖分析需求，同时确认指令I与哪些指令有依赖关系，直到依赖分析需求都被解除或逆序到达基本块入口；每遍历到一条指令X，进行如下处理：

S1：不考虑指令I和指令X的谓词域(条件域)，分析指令I和指令X之间是否有依赖关系。如果没有，结束对指令X的处理；否则进行下面步骤的处理；

S2：获得指令X的谓词域信息，并根据指令I和指令X的条件执行关系，决定是否结束对指令X的后续处理；

S3：如果还没有结束对指令X的处理，针对指令I的依赖分析需求，结合指令X的条件执行特性开展相应的依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。

在本发明中，本发明将硬件资源配置、访问存储器、使用变量这三种导致DSP的指令间存在依赖关系的主要原因对应成指令进行依赖关系分析的处理需求，分别称为配置依赖分析需求、访存依赖分析需求、变量依赖分析需求。即在上述步骤中，如步骤S5中，是针对指令I的配置依赖分析需求、访存依赖分析需求、变量依赖分析需求，结合指令X的条件执行特性开展相应的配置依赖分析、访存依赖分析、变量依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。

鉴于造成依赖的原因有硬件资源配置、访问存储器、使用符号变量等3种主要原因，所以在分析一条指令的依赖关系时，就考虑相应的3种依赖关系分析需求。在逆序遍历前驱指令的过程中，尝试解除这些需求，直到3种需求全部解除，即终止对此指令的依赖关系分析。其中的某一种需求一旦解除，在后续继续尝试解除其他需求的过程中，这种需求就不用再考虑了，也就不会引起相应的依赖关系的建立。本发明目的是避免间接的传递依赖关系出现在指令的依赖关系描述中，从而为相关的优化提供准确的信息。本发明在各种依赖关系分析中，在分析对一个变量的赋值(即定值)时，特别考虑了互补条件执行的两条指令等效于一条无条件执行指令这种事实。

针对支持谓词执行的嵌入式处理器，为了进行精准的依赖关系分析，本发明正是考虑了指令的条件执行，特别是互补条件执行的情况，对传统的基本块内指令间依赖关系分析方法进行了如下改进：一是增加了硬件资源配置依赖类别的分析(因为对于嵌入式处理器，通过某条配置指令修改了硬件配置参数，将使得其后的指令执行时涉及的硬件资源不同，所以这里设置了配置依赖这种类别)。二是区别无条件执行、条件执行、互补条件执行等情况，分析访问存储器的指令之间的依赖关系，分析指令间因对变量的读写造成的依赖关系。

在本发明中，在为基本块内的指令1分析依赖关系之前，可以先对指令I进行预处理，为后续分析过程确定初始信息；在本实施例中，该预处理的过程包括：

a、根据指令I所使用的源变量和目标变量，创建依赖变量集合；

b、分析出指令I的谓词域的执行条件变量和条件模式；

c、假定指令I对应的三种依赖分析需求都未解除，将相应的标志位置为FALSE(假)。

在本发明中，步骤S3为对指令I进行各种依赖分析需求，在本实施例中包括：

S301：如果指令I的配置依赖分析需求尚未解除，则考虑谓词执行特性，分析指令I对指令X是否确实存在配置依赖，分析指令I的硬件配置依赖分析需求是否可以因指令X而解除。如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条配置依赖指令的执行条件互补，则可以解除；

S302：如果指令I和指令X都是访存指令且指令I的访存依赖分析需求尚未解除，则考虑谓词执行特性，分析指令I对指令X是否确实存在访存依赖，分析I的访存依赖分析需求是否可以因指令X而解除。如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条访存依赖指令的执行条件互补，则可以解除；

S303：如果指令I的所有变量依赖分析需求尚未全部解除，则考虑谓词执行特性，分析指令I对指令X是否确实因某些变量而存在依赖，分析指令I的这些变量对应的变量依赖分析需求是否可以因指令X而解除。如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条变量依赖指令的执行条件互补，则可以解除。在此基础上，进一步分析指令I的所有变量对应的变量依赖分析需求是否都已经解除。如果是，则指令I的变量依赖分析需求完整解除。

以下为本发明在一个具体应用实例中的应用。由于在面向对象语言程序中，数据和相关的功能模块都封装在类中。本发明方法涉及的实施内容可以封装到一个或多个依赖关系分析类中。由于本发明只涉及基本块内指令间依赖关系分析问题，所以：对于实施本方法所需的基本块信息、指令序列信息、指令各个域的信息等基本代码信息，假定它们是已经保存在相关的基本块类对象和指令类对象之中；对于指令模板信息，假定它们保存在指令模板类的对象中；对于体系结构的基本信息，假定它们已经保存在体系结构类对象中。它们都可以通过诸如指针或者全局变量名等方式来访问。所以，在下面的具体实施实例中，只涉及与本发明相关的基本块内指令间依赖关系分析方法直接相关的内容。

数据结构构造：

为了实现本发明的面向谓词执行的基本块内指令间依赖关系分析方法，需要相关数据结构的支持。假定当前被处理的指令I用Icur表示，I之前的某条指令X用Ipre表示，Ipre与Icur之间的某条指令用Ia表示。需要为本发明方法特别构造的主要数据结构及其说明如下：

a)Icur包含的源变量集合、目标变量集合。用于描述Icur中所有变量信息；

b)Icur的依赖变量集合、各种依赖关系分析需求对应的标志。前者是变量依赖分析时要处理的变量集合，后者是分析过程中所需要的一些开关量；

c)Icur的依赖指令集合、被依赖指令集合。两个集合中的元素分别是Icur所依赖的其他指令和其他依赖于Icur的指令。这些集合的内容是在分析过程中添加进来的；

d)指令集中所有硬件配置指令的特殊助记符集合。保存所有配置指令的特殊助记符，用于之后的查询；

e)Icur的各种依赖因素对应的不再考虑的被依赖指令条件量名称集合，称SNC。这个集合中的元素将用于判断Icur是否对条件执行的Ipre有依赖。配置依赖关系对应一个SNC，访存依赖关系对应一个SNC，指令的每个变量对应一个SNC；

f)Icur的配置依赖信息、访存依赖信息、各变量的依赖信息。它们分别用于存储处理各Ipre过程中进行配置依赖分析、访存依赖分析、变量依赖分析时得到的一些具体信息，主要包括Ipre及其条件量、条件模式信息；

g)Icur可能解除部分变量依赖分析需求时所涉及的变量名构成的集合Sa；

h)每条指令需要的辅助数据：条件模式，表示是否要对条件域中的条件变量的值取逻辑非；条件变量，指令条件域中出现的变量名。

顶层流程控制：

顶层控制过程由如附图1所示的操作状态转换图来描述。图1是基本块内的指令I与其前面的某条指令X的依赖关系分析的操作状态转换图。根据该图对应的过程，可以判定I对X是否有依赖，以及可以解除哪些依赖分析需求。图中每个操作状态说明如下：

状态1-1：备份Icur的源变量和目标变量到不同集合；

状态1-2：根据Icur的源变量和目标变量集合，创建Icur的依赖变量集合；

状态1-3：获得Icur的条件模式和条件变量名。如果Icur无条件域，则所得的模式和变量名都为空；

状态1-4：初始化各种依赖关系分析需求标识为真(TRUE)。这里的标识包括配置依赖分析、访存依赖分析、各变量依赖分析所对应的需求标识。如果Icur不是访存指令，则将访存依赖分析需求标识设置为假(FALSE)；

状态1-5：把Icur作为Ipre；

状态1-6：切换到Ipre的前一条指令，把它作为新的Ipre；

状态1-7：对Icur和Ipre的基本依赖关系进行预判定。这是忽略两条指令的条件域，根据两条指令涉及的操作类型、是否涉及存储器、涉及的变量来对它们是否有依赖关系、有什么样的依赖关系进行判断；

状态1-8：获得Ipre的条件模式和条件量；

状态1-9：判断Ipre与Icur的是否互补条件执行。即分析是否两者的条件量相同但条件模式相反，且条件量A在“[Ipre，Icur)”区间内没有可能重新定值；

状态1-10：设Ipre与Icur之间存在依赖关系，将依赖标志设置为真(TRUE)；

状态1-11：配置依赖关系分析，并视情况修改依赖标志；

状态1-12：访存依赖关系分析，并视情况修改依赖标志；

状态1-13：变量依赖关系分析，并视情况修改依赖标志；

状态1-14：如果依赖标志为真，描述Icur与Ipre之间的依赖关系；

状态1-15：判断全部依赖已解除，或逆序遍历指令完成；

状态1-16：清空、复位依赖关系分析过程涉及的所有数据。

附图1中具体每个条件说明如下：

条件(1)：遍历到达指令链首；

条件(2)：遍历未到达链首；

条件(3)：Icur与Ipre之间有基本依赖关系；

条件(4)：Icur与Ipre之间无基本依赖关系；

条件(5)：Ipre与Icur是互补条件执行关系；

条件(6)：Ipre与Icur不是互补条件执行关系；

条件(7)：Icur的全部依赖分析需求已解除，或Ipre到达基本块入口；

条件(8)：Icur的还有依赖分析需求未解除，且Ipre未到达基本块入口。

配置依赖分析：

配置依赖关系分析过程的操作状态转换图如图2所示，根据该图对应的过程，可以判定I对X是否有配置依赖。具体每个操作状态说明如下：

P.1：开始配置依赖分析过程；

P.2：判断Icur的配置依赖分析需求是否已解除；

P.3：开始尝试解除配置依赖分析需求；

P.4：判断Ipre是否为无条件执行指令；

P.5：解除Icur的配置依赖分析需求；

P.6：清空配置依赖信息；

P.7：判断Ipre的条件量是否在SNC中？

P.8：判断Ipre的条件量是否还没有在Icur的配置依赖信息中？

P.9：将Ipre及其条件量、条件模式信息添加到Icur的条件配置依赖信息中；

P.10：判断Ipre与(Icur的配置依赖信息中)某条被依赖配置指令Ia是否构成互补条件执行关系？

P.11：从依赖信息中删除与Ipre的条件量A相关的条件依赖信息；

P.12：将A添加到Icur的被依赖指令不再考虑条件量集合SNC中；

P.13：设置Ipre与Icur的配置依赖标识为假(FALSE)；

P.14：结束配置依赖处理。

如图2所示具体每个条件说明如下：

条件(1)：配置依赖已解除；

条件(2)：配置依赖未解除；

条件(3)：Icur和Ipre都是配置指令，或Ipre不是配置指令且Icur是配置指令；

条件(4)：Ipre是配置指令且Icur是非配置指令，或Ipre和Icur都是配置指令；

条件(5)：Ipre是无条件执行指令；

条件(6)：Ipre不是无条件执行指令；

条件(7)：Ipre的条件量A在SNC中；

条件(8)：Ipre的条件量A不在SNC中；

条件(9)：Ipre的条件量A还没有在Icur的配置依赖信息中；

条件(10)：Ipre的条件量A已经在Icur的配置依赖信息中；

条件(11)：Ipre与Ia互补条件执行；

条件(12)：Ipre与Ia是具有相同条件变量的条件执行指令，且条件量A在Ipre与Ia之间可能被其他指令修改；

条件(13)：Ipre与Ia是具有相同条件变量、相同条件模式的条件执行指令。

访存依赖分析：

访存依赖关系分析的操作状态转换图如图3所示，根据该图对应的过程，可以判定I对X是否有访存依赖。具体每个状态说明如下：

M.1：开始访存依赖分析；

M.2：判断访存依赖未解除，且Ipre和Icur都是访存指令，且Ipre是向存储器存数据的指令这些条件是否被满足？

M.3：判断Ipre是否为无条件执行指令？

M.4：解除访存依赖分析需求；

M.5：清空访存依赖信息；

M.6：判断Ipre的条件量是否在SNC中？

M.7：判断Ipre的条件量是否还没有在Icur的访存依赖信息中？

M.8：将Ipre及其条件量、条件模式信息添加到Icur的条件访存依赖信息中；

M.9：判断Ipre与Icur的访存依赖信息中某条被依赖访存指令Ia是否构成互补条件执行关系？

M.10：从依赖信息中删除与Ipre的条件量A相关的信息；

M.11：将A添加到Icur的被依赖指令不再考虑条件量集合SNC中；

M.12：设置Ipre与Icur的访存依赖标识为假(FALSE)；

M.13：结束访存依赖处理。

图3中具体每个条件说明如下：

条件(1)：访存依赖已解除，或Ipre或Icur不是访存指令，或Ipre不是存储数据到存储器的指令；

条件(2)：访存依赖未解除，且Ipre和Icur都是访存指令，且Ipre是向存储器存数据的指令；

条件(3)：Ipre是无条件执行指令；

条件(4)：Ipre不是无条件执行指令；

条件(5)：Ipre的条件量A在SNC中；

条件(6)：Ipre的条件量A不在SNC中；

条件(7)：Ipre的条件量A还没有在Icur的访存依赖信息中；

条件(8)：Ipre的条件量A已经在Icur的访存依赖信息中；

条件(9)：Ipre与Ia是互补条件执行关系；

条件(10)：Ipre与Ia是具有相同条件变量的条件执行指令，且条件量A在Ipre与Ia之间可能被其他指令修改；

条件(11)：Ipre与Ia是具有相同条件变量、相同条件模式的条件执行指令。

变量依赖分析：

变量依赖关系分析过程的操作状态转换图如图4所示，根据该图对应的过程，可以判定I因哪些变量而依赖于X。具体每个状态说明如下：

V.1：开始变量依赖分析；

V.2：判断Icur的变量依赖分析需求是否未解除？

V.3：判断能消除部分变量依赖(考虑部分定值)？

V.4：获得相关的可能被消除依赖量x的集合Sa；

V.5：判断Ipre是无条件执行指令？

V.6：解除对Sa中各元素x的变量依赖，删除Sa中的各元素及其对应的依赖信息(含条件依赖)；

V.7：如果Icur的依赖量集合为空，解除的变量依赖分析需求，清空变量依赖信息；

V.8：切换到Sa中的下一个元素，设其为x。如果是第一次进入此状态，x为Sa中的第一个元素；

V.9：判断Ipre执行条件量A是否在x的不考虑的条件量集合SNC中？

V.10：判断Ipre的条件量是否已经在x的条件依赖信息中？

V.11：为x添加依赖指令及其条件量和条件模式信息到相应的条件依赖信息对象中；

V.12：切换x为sa中的下一个元素；

V.13：判断Ipre与已经发现的x相关被依赖指令Ia是否构成互补条件执行关系？

V.14：从各数据结构中删除x的与Ipre的条件量A相关条件依赖信息；

V.15：将A添加到x的被依赖指令不再考虑条件量集合SNC中；

V.16：设置Ipre与Icur的变量依赖标识为假(FALSE)；

V.17：从各数据结构中删除x及其对应的条件依赖信息；

V.18：结束变量依赖处理。

图4中具体每个条件说明如下：

条件(1)：变量依赖分析需求未解除；

条件(2)：变量依赖分析需求已解除；

条件(3)：能为Icur消除部分变量依赖；

条件(4)：不能为Icur消除部分变量依赖；

条件(5)：Ipre是无条件执行指令；

条件(6)：Ipre不是无条件执行指令；

条件(7)：Ipre执行条件量A在x的不考虑的条件量集合SNC中；

条件(8)：Ipre执行条件量A不在x的不考虑的条件量集合SNC中；

条件(9)：Ipre的条件量已经在x的条件依赖信息中；

条件(10)：Ipre的条件量不在x的条件依赖信息中；

条件(11)：Ipre和Ia构成互补条件执行对x定值；

条件(12)：Ipre与Ia是具有相同条件变量的条件执行指令，且条件量A在Ipre与Ia之间可能被其他指令修改；

条件(13)：Ipre与Ia是具有相同条件变量、相同条件模式的条件执行指令；

条件(14)：对Sa内容的遍历已完成；

对Sa内容的遍历未完成。

以上仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，应视为本发明的保护范围。

Claims (8)

1.一种面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，对于基本块内的指令I，从指令I的前一条指令开始，逆序遍历基本块内的指令去尝试解除依赖分析需求，同时确认指令I与哪些指令有依赖关系，直到依赖分析需求都被解除或逆序到达基本块入口；每遍历到一条指令X，进行如下处理：

S1：不考虑指令I和指令X的谓词域，分析指令I和指令X之间是否有依赖关系；如果没有，结束对指令X的处理；否则进行下面步骤的处理；

S2：获得指令X的谓词域信息，并根据指令I和指令X的条件执行关系，决定是否结束对指令X的后续处理；

S3：如果还没有结束对指令X的处理，针对指令I的依赖分析需求，结合指令X的条件执行特性开展相应的依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。

2.根据权利要求1所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，将硬件资源配置、访问存储器、使用变量这三种导致DSP的指令间存在依赖关系的主要原因对应成指令进行依赖关系分析的处理需求，分别称为配置依赖分析需求、访存依赖分析需求、变量依赖分析需求。

3.根据权利要求2所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，在步骤S3中，是针对指令I的配置依赖分析需求、访存依赖分析需求、变量依赖分析需求，结合指令X的条件执行特性开展相应的配置依赖分析、访存依赖分析、变量依赖分析，确定指令I是否确实依赖于指令X，并尝试解除相应的依赖分析需求。

4.根据权利要求1或2或3所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，在为基本块内的指令I分析依赖关系之前，先对指令I进行预处理，为后续分析过程确定初始信息。

5.根据权利要求4所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，所述预处理的过程包括：

a、根据指令I所使用的源变量和目标变量，创建依赖变量集合；

b、分析出指令I的谓词域的执行条件变量和条件模式；

c、假定指令I对应的三种依赖分析需求都未解除，将相应的标志位置为FALSE。

6.根据权利要求2或3所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，所述步骤S3为对指令I进行各种依赖分析需求，包括：

如果指令I的配置依赖分析需求尚未解除，则考虑谓词执行特性，分析指令I对指令X是否确实存在配置依赖，分析指令I的硬件配置依赖分析需求是否可以因指令X而解除；如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条配置依赖指令的执行条件互补，则可以解除。

7.根据权利要求2或3所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，所述步骤S3为对指令I进行各种依赖分析需求，包括：

如果指令I和指令X都是访存指令且指令I的访存依赖分析需求尚未解除，则考虑谓词执行特性，分析指令I对指令X是否确实存在访存依赖，分析I的访存依赖分析需求是否可以因指令X而解除；如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条访存依赖指令的执行条件互补，则可以解除。

8.根据权利要求2或3所述的面向谓词执行高性能DSP的指令依赖关系分析方法，其特征在于，所述步骤S3为对指令I进行各种依赖分析需求，包括：

如果指令I的所有变量依赖分析需求尚未全部解除，则考虑谓词执行特性，分析指令I对指令X是否确实因某些变量而存在依赖，分析指令I的这些变量对应的变量依赖分析需求是否可以因指令X而解除；如果指令X是无条件执行指令，或者指令X是条件执行指令并且其执行条件与之前已经发现的另一条变量依赖指令的执行条件互补，则可以解除；在此基础上，进一步分析指令I的所有变量对应的变量依赖分析需求是否都已经解除；如果是，则指令I的变量依赖分析需求完整解除。