We will continue our reading of this WRL research report. We now discuss the results of the Swift IR. Among the several optimizations facilitated by Swift IR, the rule for determining if values are equivalent and therefore can be eliminated as a common subexpression, works for all operations. Further, identical operations with equivalent inputs are equivalent because the global store inputs conservatively represent the memory dependences and all other true data dependences are explicit in the inputs to the values. Together these rules imply that the common subexpression elimination (CSE) can be applied to all values including memory reads. Values will be candidates for CSE only if they access the same field and they have the same global store input. This principle is applied even at the time of building the SSA graph.These rules are applied over and over again in many passes of the compiler.
The SSA graph makes all data flow and ordering dependences explicit. This is a tremendous advantage because optimizations now follow a single data structure. Although anti-dependences are not explicitly represented and must be generated during scheduling passes, the Swift IR enforces them via explicit checks instead. In addition, Swift IR pins various operations to their basic blocks. All other values are explicitly moved around subject to scheduling constraints. Like CSE, scheduling is still simple enough that several passes in Swift do limited form of scheduling to see if some other optimization would be useful.
Method inlining is applied by requiring dependences between values in the inlined method and the values in the calling method. It just produces a slightly larger SSA graph. All the code optimizations such as CSE, code motion, and dead-code elimination, apply after method inlining without any artificial restrictions.
One of the findings from this study is that SSA improves the effectiveness of peephole optimizations.
#coding exercise
How can we differentiate if a given email alias is that of an individual or a distribution list:
The SSA graph makes all data flow and ordering dependences explicit. This is a tremendous advantage because optimizations now follow a single data structure. Although anti-dependences are not explicitly represented and must be generated during scheduling passes, the Swift IR enforces them via explicit checks instead. In addition, Swift IR pins various operations to their basic blocks. All other values are explicitly moved around subject to scheduling constraints. Like CSE, scheduling is still simple enough that several passes in Swift do limited form of scheduling to see if some other optimization would be useful.
Method inlining is applied by requiring dependences between values in the inlined method and the values in the calling method. It just produces a slightly larger SSA graph. All the code optimizations such as CSE, code motion, and dead-code elimination, apply after method inlining without any artificial restrictions.
One of the findings from this study is that SSA improves the effectiveness of peephole optimizations.
#coding exercise
How can we differentiate if a given email alias is that of an individual or a distribution list:
def validateByLDAP(email, password, alias = None):
ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
ld.set_option(ldap.OPT_REFERRALS, 0)
ld.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
ld.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_DEMAND)
ld.set_option(ldap.OPT_X_TLS_DEMAND, True)
ld.set_option(ldap.OPT_DEBUG_LEVEL, 255)
ld.simple_bind_s(email, password)
if not alias:
raise "Invalid email alias"
base_dn = "cn=users,dc=abcnet,dc=global,dc=abc,dc=com"
filter = "(samaccountname="+ name +")"
results = ld.search_s(base_dn,ldap.SCOPE_SUBTREE, filter, ['sn'])
print repr(results)
return results
returns '' for an alias that does not belong to an individual otherwise
returns an array with a match found
returns '' for an alias that does not belong to an individual otherwise
returns an array with a match found
No comments:
Post a Comment