>
> This expands on implementation details, compares different approaches
> (in-memory vs. RPC-based solutions), and identifies relevant GCC components
> to modify.
>
> 1. Overview of Implementation Approaches
>
> Currently, GCC’s GPU offloading test framework lacks support for file I/O,
> causing many test cases to fail. To solve this, two primary solutions are
> proposed:
>
>
> 1.
>
> In-Memory File System (Preferred Approach)
>
>
> -
>
> Implement a simple file system that operates entirely in volatile
> memory
> -
>
> Provides an interface for file operations (open(), read(), write(),
> etc.).
> -
>
> Integrated directly within the libgomp OpenMP runtime for GPUs.
>
>
> Remote Procedure Call (RPC) File System
>
> -
>
> Implements a host-GPU communication channel using RPC mechanisms.
> -
>
> Allows the GPU to request file operations on the host (like read(),
> write()).
> -
>
> Requires a runtime service running on the host that interacts with the
> GPU.
>
>
> Both approaches have trade-offs, which are discussed below.
>
> 2. Detailed Implementation Plan
>
> Approach 1: In-Memory File System
>
> Concept:
>
> This approach mimics a file system within memory.
>
> Useful for temporary file operations required during GPU execution.
>
> Works best when file persistence isn’t required beyond test execution.
>
> Key Components:
>
> A global data structure (gpu_file_table[]) to store file descriptors and
> file contents.
>
> Functions for standard file operations:
>
> -
>
> gpu_fopen() → Opens a file in memory.
> -
>
> gpu_fwrite() → Writes to the in-memory buffer.
> -
>
> gpu_fread() → Reads file content.
> -
>
> gpu_fclose() → Closes a file and releases memory.
>
>
> Integration with GCC:
>
> -
>
> Modify libgomp to introduce these functions (libgomp/gpu_file_io.c).
> -
>
> Override existing file I/O calls in OpenMP test cases to use the
> in-memory system.
>
>
> *Pros and Cons:*
>
> Pros:
>
> 1.
>
> Fast: No network latency.
> 2.
>
> Self-contained: Works independently of the host.
> 3.
>
> Minimal modifications: Only requires changes in libgomp.
>
> Cons:
>
> 1.
>
> Files disappear after execution.
> 2.
>
> Limited size: Memory constraints may prevent large file operations.
>
> Approach 2: RPC-Based File System
>
> Concept:
>
> 1.
>
> Uses an RPC server on the host to handle file requests from the GPU.
> 2.
>
> GPU communicates with the host via PCIe, shared memory, or
> socket-based RPC.
> 3.
>
> Suitable for real-world file interactions where data persistence is
> required.
>
> Key Components:
>
> -
>
> Host-side daemon (gpu_fs_server)
> -
>
> Runs in the background and listens for GPU file access requests.
> -
>
> Handles operations like open(), read(), write(), close().
> -
>
> GPU Runtime Library (gpu_fs_client)
> -
>
> GPU sends file requests to the host via RPC calls.
> -
>
> Waits for responses and returns data to the calling program.
>
> Integration with GCC:
>
> Modify libgomp/nvptx.c and libgomp/gcn.c to call RPC file system functions.
>
> Modify OpenMP test cases to use host files via RPC.
>
> *Pros and Cons:*
>
> Pros
>
> 1.
>
> Persistent file storage: Files remain available after execution.
> 2.
>
> Supports larger files: Not limited by GPU memory.
> 3.
>
> Closer to real-world applications that access disk files.
>
> Cons:
>
> 1.
>
> Network/PCIe overhead: Slower than in-memory operations.
> 2.
>
> Additional complexity: Requires host-side service and GPU
> communication handling.
> 3.
>
> Synchronization challenges: Needs efficient queueing and handling of
> file requests.
>
> 3. Integration with GCC Test Harness
>
> Both approaches require modifications to GCC’s test framework (DejaGNU) to
> ensure GPU tests correctly handle file I/O.
>
> Key Files in GCC:
>
> 1.
>
> libgomp/testsuite/lib/libgomp.exp
>
> Contains test execution logic for OpenMP offloading.
>
> Needs modifications to redirect file I/O to the new file system.
>
> 2.
>
> libgomp/nvptx.c (Nvidia GPUs) & libgomp/gcn.c (AMD GPUs)
>
> Contains the GPU offloading runtime.
>
> Will be updated to intercept file system calls.
>
> libgomp/libgomp.h (OpenMP Headers)
>
> Needs new function declarations for gpu_fopen(), gpu_fwrite(), etc.
>
> 3.
>
> libgomp/gpu_file_io.c
>
> New file to implement in-memory file operations.
>
> 4. Existing Functionality to Build Upon
>
> -
>
> OpenMP Offloading in GCC
> -
>
> GCC already supports offloading OpenMP/OpenACC programs to GPUs.
> -
>
> This project extends its ability to handle file I/O in offloaded
> execution.
> -
>
> GCC’s DejaGNU Framework
> -
>
> Used for automated testing.
> -
>
> The new file system will integrate with DejaGNU to improve GPU test
> coverage.
> -
>
> Precedents in LLVM & CUDA
> -
>
> LLVM has better support for GPU file I/O testing.
> -
>
> CUDA supports some basic file system operations.
> -
>
> GCC can adopt similar strategies.
>
>
> *5. Open Questions for Further Discussion*
>
> -
>
> Preferred Approach?
> -
>
> Should the initial focus be on in-memory file support, with RPC as
> a later improvement?
> -
>
> Handling Large Files?
> -
>
> If an in-memory solution is used, should we limit file sizes or
> allow swapping to host memory?
> -
>
> Testing & Debugging Strategy?
> -
>
> How to efficiently test and debug GPU file system interactions?
>
>
> *6. Conclusion & Next Steps*
>
> Immediate Action Items:
>
> Implement basic in-memory file I/O functions (gpu_fopen(), gpu_fwrite(),
> etc.).
>
> Modify OpenMP test cases to use these functions.
>
> Benchmark performance of in-memory vs. RPC approaches.
>
> Engage with GCC maintainers to gather feedback.
>
>
>
>
