Rather than build the latch out of combinatorial gates, take advantage of the latch primitive's reset input:

clearable_latch : process(le, clr, d) is
begin
    if (clr = '1') then
        q <= '0';
    else if (le = '1') then
        q <= d;
    end if;
end process clearable_latch;

which infers an LDC element using the slice's storage element. Note that the clr input has priority over the latch enable, which is the usual and expected operation. This code doesn't use any of the slice's LUT, just the storage element.

A proper latch element is considered "safer" than one built out of gates.

Adding a gate enable infers the LDCE element:

clearable_enabled_latch : process(le, clr, ce, d) is
begin
    if (clr = '1') then
        q <= '0';
    else if ((le = '1') and (ce = '1')) then
        q < = d;
    end if;
end process clearable_enabled_latch;

which still uses only the slice's storage element and none of the LUT. The gate enable can be more complicated (although I would write an explicit equation for the ce signal rather than cluttering up the sensitivity list):

clearable_enabled_latch_2 : process (le, clr, addr, d) is
begin
    if (clr = '1') then
        q <= '0';
    else if ((le = '1') and (addr = REGADDR)) then
        q <= d;
    end if;
end process clearable_enabled_latch_2;

The address compare gets handled by LUTs and that result drives the storage element's CE input.

Building a latch out of gates may be interesting but it's grossly inefficient if you need to describe an 8-bit wide latch. Then the HDL descriptions above are simpler. Replace the q <= '0'; in the clear terms with q <= (others => '0'); and make sure q and d are std_logic_vector(LENGTH-1 downto 0) and you're good.

BTW: the Xilinx Libraries Guide shows the various elements available in both schematics and the result of HDL inference.

I will simulate the latch-of-gates tomorrow morning ... I have a feeling the combinatorial feedback will cause ModelSim to dump core, or something.

-a