Shiyi Wei

Simin Chen, Shiyi Wei, Cong Liu et al.

DL compiler's primary function is to translate DNN programs written in high-level DL frameworks such as PyTorch and TensorFlow into portable executables. These executables can then be flexibly executed by the deployed host programs. However, existing DL compilers rely on a tracing mechanism, which involves feeding a runtime input to a neural network program and tracing the program execution paths to generate the computational graph necessary for compilation. Unfortunately, this mechanism falls short when dealing with modern dynamic neural networks (DyNNs) that possess varying computational graphs depending on the inputs. Consequently, conventional DL compilers struggle to accurately compile DyNNs into executable code. To address this limitation, we propose \tool, a general approach that enables any existing DL compiler to successfully compile DyNNs. \tool tackles the dynamic nature of DyNNs by introducing a compilation mechanism that redistributes the control and data flow of the original DNN programs during the compilation process. Specifically, \tool develops program analysis and program transformation techniques to convert a dynamic neural network into multiple sub-neural networks. Each sub-neural network is devoid of conditional statements and is compiled independently. Furthermore, \tool synthesizes a host module that models the control flow of the DyNNs and facilitates the invocation of the sub-neural networks. Our evaluation demonstrates the effectiveness of \tool, achieving a 100\% success rate in compiling all dynamic neural networks. Moreover, the compiled executables generated by \tool exhibit significantly improved performance, running between $1.12\times$ and $20.21\times$ faster than the original DyNNs executed on general-purpose DL frameworks.

Kishan Rakesh, Shiyi Wei

[Context] Screen reader users navigating webpages by element list often encounter accessible names such as "Read more" that are valid under the W3C Accessible Name and Description Computation specification but uninterpretable in isolation. The surrounding elements that would make these names meaningful exist in the page but are not linked to the target by any mechanism. No prior work has empirically studied how to select which surrounding elements are contextually relevant to a given target. [Objective] This registered report investigates whether human-perceived contextual associations between webpage elements can be recovered from the accessibility tree using link prediction, and whether the learned associations generalize across websites. [Method] We will construct a dataset of human-annotated contextual associations on 35 websites, stratified across the Tranco top-million list, with three independent annotators per page. Each page is represented as a graph derived from its accessibility tree, augmented with spatial and semantic features from the DOM and CSS. We compare four machine learning models (MLP, GCN, GAT, and SEAL) against two heuristic baselines under leave-one-site-out cross-validation with a pre-registered statistical framework, using Hit@K and MRR. [Results] We have conducted a five-site author-annotated pilot study to establish the pipelines and parameterize the power simulation, with pilot Hit@10 ranging from 0.16 to 0.85 across four learned models and 0.08 to 0.30 across two heuristic baselines. The final results will be reported after the planned experiments and analyses are completed. [Conclusion] The study contributes a human-annotated dataset of contextual associations on webpages, an empirical evaluation of link prediction for context selection on accessibility-tree graphs, and a cross-site generalization analysis.

Juan Manuel Florez, Laura Moreno, Zenong Zhang et al.

Software systems are designed according to guidelines and constraints defined by business rules. Some of these constraints define the allowable or required values for data handled by the systems. These data constraints usually originate from the problem domain (e.g., regulations), and developers must write code that enforces them. Understanding how data constraints are implemented is essential for testing, debugging, and software change. Unfortunately, there are no widely-accepted guidelines or best practices on how to implement data constraints. This paper presents an empirical study that investigates how data constraints are implemented in Java. We study the implementation of 187 data constraints extracted from the documentation of eight real-world Java software systems. First, we perform a qualitative analysis of the textual description of data constraints and identify four data constraint types. Second, we manually identify the implementations of these data constraints and reveal that they can be grouped into 30 implementation patterns. The analysis of these implementation patterns indicates that developers prefer a handful of patterns when implementing data constraints and deviations from these patterns are associated with unusual implementation decisions or code smells. Third, we develop a tool-assisted protocol that allows us to identify 256 additional trace links for the data constraints implemented using the 13 most common patterns. We find that almost half of these data constraints have multiple enforcing statements, which are code clones of different types.

George Klees, Andrew Ruef, Benji Cooper et al.

Fuzz testing has enjoyed great success at discovering security critical bugs in real software. Recently, researchers have devoted significant effort to devising new fuzzing techniques, strategies, and algorithms. Such new ideas are primarily evaluated experimentally so an important question is: What experimental setup is needed to produce trustworthy results? We surveyed the recent research literature and assessed the experimental evaluations carried out by 32 fuzzing papers. We found problems in every evaluation we considered. We then performed our own extensive experimental evaluation using an existing fuzzer. Our results showed that the general problems we found in existing experimental evaluations can indeed translate to actual wrong or misleading assessments. We conclude with some guidelines that we hope will help improve experimental evaluations of fuzz testing algorithms, making reported results more robust.